Best possible solution:

Land the shared capability-profile fix only after maintainers accept that wildcard sender policy is for unidentified or external senders, while keeping external channels and non-owner WebChat restricted by the new tests.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection shows current main always resolves sender policy and resolveToolsBySender falls back to the wildcard for sender-less WebChat owner turns; I did not run the live WebChat scenario in this read-only review.

Is this the best way to solve the issue?

Yes, with maintainer acceptance. The shared capability-profile layer is the narrow maintainable fix because core tool construction, plugin harness policy, and /learn availability all consume that policy decision; the unresolved part is the intended wildcard security contract.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against e024eacf176c.

Label justifications:

• P2: The PR fixes a bounded owner WebChat tool-access regression for installations with restrictive sender policy, with limited blast radius.
• merge-risk: 🚨 compatibility: The diff changes how an existing toolsBySender["*"] config behaves for authenticated owner WebChat turns.
• merge-risk: 🚨 security-boundary: The diff intentionally broadens shell, filesystem, and process tool availability for authenticated internal WebChat owners under a previously restrictive sender policy.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The external-contributor proof gate does not apply to this maintainer-labeled MEMBER PR, and the PR body nevertheless includes live authenticated WebChat before/after tool-count proof plus a shell command run.

PR surface:

Source +12, Tests +166. Total +178 across 7 files.

What I checked:

• Root and scoped policy read: Root AGENTS.md and src/agents/AGENTS.md were read fully; the review applied the repo guidance that sender policy, plugin harness behavior, auth/session state, and security boundaries are compatibility-sensitive. (AGENTS.md:27, e024eacf176c)
• Current main applies sender policy unconditionally: Current main always resolves senderPolicy inside the shared capability profile, so a WebChat owner turn without a sender identity can fall through to wildcard toolsBySender. (src/agents/conversation-capability-profile.ts:209, e024eacf176c)
• Wildcard fallback is the current source behavior: matchToolsBySenderPolicy returns the compiled wildcard when no channel/id/e164/username/name sender candidate matches. (src/config/group-policy.ts:309, e024eacf176c)
• WebChat owners are identified by gateway admin scope: The Control UI/WebChat send path sets senderIsOwner: true for gateway-admin clients and builds the message context with the internal webchat provider/surface. (src/gateway/server-methods/chat.ts:4394, e024eacf176c)
• PR implements the shared owner-WebChat exception: At the PR head, resolveConversationCapabilityProfile skips sender policy only when senderIsOwner is true and the normalized provider or message channel is the internal WebChat channel. (src/agents/conversation-capability-profile.ts:211, eba344e32bc4)
• Plugin harness and /learn paths receive owner identity: The PR passes senderIsOwner into the plugin harness capability-profile resolver and into the /learn workshop availability check, avoiding a one-sided core-tool-only fix. (src/agents/harness/selection.ts:467, eba344e32bc4)

Likely related people:

• steipete: Current blame for the shared capability-profile, plugin-harness policy path, and WebChat sender-owner propagation points to the merged refactor(codex): raise app-server floor to 0.142, drop range compat, fix deferred spawn_agent steering #101221 refactor authored and merged by steipete; the live PR is also assigned to steipete. (role: recent area contributor and current assignee; confidence: high; commits: e5798e547770; files: src/agents/conversation-capability-profile.ts, src/agents/harness/selection.ts, src/gateway/server-methods/chat.ts)
• fuller-stack-dev: Beyond authoring this PR, fuller-stack-dev has prior merged WebChat gateway work in feat(gateway): persist webchat inbound images to disk #51324 touching the same gateway chat surface. (role: recent adjacent WebChat contributor; confidence: medium; commits: c9449d77b40a; files: src/gateway/server-methods/chat.ts)
• obviyus: obviyus merged the prior WebChat image persistence PR and authored follow-up commits in that gateway chat path, making them relevant for adjacent WebChat behavior context. (role: adjacent merger/reviewer; confidence: medium; commits: 7a22cc1592de, 2e72ff2a659e; files: src/gateway/server-methods/chat.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

• reviewed 2026-07-07T02:36:33.533Z sha 1e475c5 :: needs maintainer review before merge. :: none