[bwachman]

Summary

• The worker grant identity (tool, arguments, cwd) is computed from the call as DynamicToolRunner dispatches it, through the same prepareDispatchedToolCall coercion, at both the reactor authorize stage and the permission middleware. An authorized retry of a gpt-family shell call now executes exactly once.
• Before, authorize keyed the grant on the raw wire call (shell with {command, timeout, cwd, background, stop}), while the middleware saw the coerced run_shell {command}. The envelope was authorized under the first fingerprint, the middleware missed it, re-evaluated to ask, and blocked the approved retry under a new grant request.
• Envelopes now freeze the dispatched arguments, so the parent approves exactly what runs. A replay is still denied as consumed, and a changed command is still denied at both stages.

Stacked on #1520; review that first. The diff against its branch is this change only.

Verification

• bun run check passes (9237 tests)
• The new test runs the live gpt-family shell call through the real permission gate, worker gate, grant store, dispatch coercion and permission middleware. On the base branch the approved retry is blocked and a new grant request is minted; here it executes once, a replay is denied and an altered command is denied.
• Live, interactive TUI without yolo, gpt-family model, on a build of this branch (with fix(tui): deliver approvals for parked calls in queue-drained turns #1519 and fix(session): release a settled approval overlay before delivering #1520): worker shell call denied, ask_director, approve_worker_call approved, nested prompt for the frozen call approved, then the worker's retry executed exactly once and returned the command's real result. Before this change the approved retry was blocked under a new grant request.

Fixes CL-10855
Part of CL-10852

[linear-code]

CL-10852

CL-10855

[TheGreatAxios]

Review · Request changes

Keys the worker-grant fingerprint on the dispatched call, so an authorized retry of a gpt-family shell call matches the coerced run_shell the middleware actually runs.

Findings

• a25ce3c4 — subject test(permission): cover an authorized retry of a dispatch-coerced worker call is 77 characters. The cap is 72. Shorten it. The fix subject is within the cap, and both bodies are empty, which is allowed.

Code check: no defect in the fingerprint. dispatchedCall at src/permission/reactor-authorize.ts:112 runs prepareDispatchedToolCall before workerCallIdentity, and a throw keeps the raw arguments while dispatch never reaches the middleware. bun test src/permission/worker-grant-dispatch-identity.test.ts — 2 pass, 0 fail, including one execution, a consumed replay, and a changed command denied.

[bwachman]

Kept your reworded subjects through the rebase onto the updated #1520 (5390b8a, 787b80c). git range-diff shows both commits identical to your push apart from the base; no other changes.

[TheGreatAxios]

Review · Approve

Keys the worker-grant fingerprint on the dispatched call, so an authorized retry of a gpt-family shell call matches the coerced run_shell the middleware runs.

Findings

No findings.

The previous finding was the test subject length. It is now test(permission): cover an authorized coerced-shell retry (57 characters). The unique diff against the current #1520 tip is still only src/permission/reactor-authorize.ts and its test. workerCallIdentity at src/permission/reactor-authorize.ts:121 takes the tool and arguments from prepareDispatchedToolCall. The rebase did not widen the grant. bun test src/permission/worker-grant-dispatch-identity.test.ts — 2 pass, 0 fail.

[corbits-triage]

Triage: Pass

No changes needed from you. A maintainer will review this pull request.