fix(agents): preserve operator.write scope for in-process subagent spawns#99199
fix(agents): preserve operator.write scope for in-process subagent spawns#99199xiaobao-k8s wants to merge 1 commit into
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed July 10, 2026, 5:56 AM ET / 09:56 UTC. Summary PR surface: Source +3, Tests +1. Total +4 across 2 files. Reproducibility: yes. at source level: current main can inherit a channel or plugin client without Review metrics: 1 noteworthy metric.
Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review detailsBest possible solution: Keep the write-only synthetic client at the subagent chokepoint and explicit admin scope for cleanup, but land only after the auth owner approves that trust handoff and a redacted affected-channel run proves the shipped regression is fixed. Do we have a high-confidence way to reproduce the issue? Yes at source level: current main can inherit a channel or plugin client without Is this the best way to solve the issue? Yes technically: the patch is narrow, the synthetic default is write-only, and admin cleanup remains explicit. It is not merge-ready until maintainers approve the principal handoff and the contributor proves the real affected path. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 7fe004d85251. Label changesLabel justifications:
Evidence reviewedPR surface: Source +3, Tests +1. Total +4 across 2 files. View PR surface stats
Security concerns:
What I checked:
Likely related people:
What the crustacean ranks mean
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. How this review workflow works
Review history (1 earlier review cycle)
|
clawsweeper
Bot
added
rating: 🦪 silver shellfish
…bagent dispatch When in-process subagent Gateway dispatch omitted forceSyntheticClient for non-admin methods (e.g. "agent"), the call could inherit the caller's channel-plugin client, which may not carry operator.write (openclaw#98614). Always force the synthetic operator client for in-process dispatch so scope resolution does not depend on the calling channel plugin's client scopes. Closes openclaw#98614
4a43bce to
cd202ae
Compare
|
Rebased onto latest main (cd202ae) to resolve the merge conflict. No logic change — the fix remains: always force synthetic operator client for in-process dispatch. Changes vs original PR:
@clawsweeper re-review Closes #98614 |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
This pull request has been automatically marked as stale due to inactivity. |
1 participant
What Problem This Solves
Fixes an issue where
sessions_spawnfails withmissing scope: operator.writewhen triggered from a channel plugin (e.g. Google Chat) using token auth. This is a regression introduced by commit58bab0c2761which added in-process dispatch optimization tocallSubagentGateway.Before the optimization, all
callSubagentGatewaycalls went through the WebSocket connection path wherecallGatewayLeastPrivilegecorrectly resolvesoperator.writescope for theagentmethod. After the optimization, whenhasInProcessGatewayContext()is true (the common case for channel-triggered sessions), the dispatch usesdispatchGatewayMethodInProcesswhich inherits the outer request scope's client. Channel plugin clients may not carryoperator.write, causing the gateway method authorizer to reject the dispatch.Why This Change Was Made
Always set
forceSyntheticClient: truewhen dispatching in process fromcallSubagentGateway, so that non-admin methods likeagentuse the synthetic operator client (defaults toWRITE_SCOPE) instead of inheriting the calling channel plugin client's scopes. Admin-only methods (e.g.sessions.delete) continue to pass explicitsyntheticScopes: [ADMIN_SCOPE].User Impact
Users deploying OpenClaw with token auth and triggering subagent spawns from channel plugins (Google Chat, WhatsApp, Telegram, etc.) will no longer see
missing scope: operator.writeerrors. Multi-agent delegation works correctly again.Evidence
Tests pass locally:
The in-process dispatch test now verifies
forceSyntheticClient: truefor non-admin "agent" dispatches, and admin-scoped cleanup test continues to verifyforceSyntheticClient: true, syntheticScopes: ["operator.admin"]for admin methods.Real behavior proof
Behavior or issue addressed: After the fix, sessions_spawn triggered from a channel plugin (e.g. Google Chat) via token auth no longer fails with "missing scope: operator.write". The in-process dispatch for "agent" method uses the synthetic operator client with WRITE_SCOPE instead of inheriting the channel plugin client's scopes.
Real environment tested: Repository
openclaw/openclaw, branchfix/token-auth-operator-write-98614, commit4a43bcec234, using the project's test runner from a git worktree on latest main (826c84e).Exact steps or command run after this patch:
Evidence after fix: Terminal output from the verification:
Observed result after fix: The in-process dispatch test confirms forceSyntheticClient: true is set for the "agent" method (which requires operator.write), ensuring the synthetic client with [WRITE_SCOPE] is used. Admin-scoped cleanup test still passes with correct admin-tier scope override.
What was not tested: End-to-end Google Chat channel trigger with token auth — requires a live Google Chat deployment. The fix is verified at the unit level through the in-process dispatch mock assertions.
Closes #98614