[chrisohearn]

Changing Permissions on an existing server thread only wrote the composer draft. thread.runtime-mode.set went out only with the next message, so an idle thread (for example the Jarvis inbox, where any message wakes another agent) could not change mode without posting into it. Meanwhile the UI showed a mode the database did not have.

Fix

Web (useComposerSelection, useApplyThreadRuntimeMode, runtimeModePickStore)

• Idle server thread: a pick dispatches thread.runtime-mode.set right away. The pick is held in an unsaved per-thread store and shows until the thread shell has that exact mode. It is also released after a timeout or when the composer unmounts. Releasing on the command reply flashed the old mode for about 66 ms.
• Pick identity: each pick object is its own token, so a reply to an older pick never takes over a newer one.
• Refusal: shows "Could not change permissions" with the server's reason, and the control returns to the server's mode.
• Busy: a pick is refused in the client while a send or run is under way (isWorking, or either runtime source shows preparing, starting, running or waiting).
• Server threads ignore a saved draft's mode. The control shows the pending pick or the server's mode. Sends no longer set the runtime mode, because a pick applies itself.
• Local draft threads: unchanged. The mode still applies when the thread is created.

Server (Orchestrator.ts)

• An owner setting the thread's current mode is a no-op: no event, no detach.
• An owner change is refused while a run is active, if it would detach a live session. Claude cannot switch mode in a live session, so applying it would end the run. This protects every client, not just this one. The MCP lower-only rules are unchanged.

Scope

• The composer.mode keybinding opens the same menu, so it uses this path. The command palette has no permissions entry.
• Interaction mode needs no fix: no web control sets it.
• Mobile has the same gap; follow-up in Mobile: apply a thread's permissions pick right away, not on the next message #72.

Tests

• ChatView.runtimeMode.browser.test.tsx (9 cases):
  • an idle pick reaches the server before any message, and holds until the shell shows it
  • a refusal shows the reason and resets the control
  • returning to the server's mode while a pick is pending sends it, and the old refusal is ignored
  • a send while a pick is pending sends no second set
  • a mode in an older saved draft neither shows nor is sent
  • a pick is refused in each of preparing, starting, running and waiting
• runtimeLayer.test.ts: an owner's set to the current mode commits no events, and an owner's set during a run with a session that cannot switch in place is refused while the session stays running.
• The new cases fail on the previous head or on base. vp run check:changed passes.

Live check

Ran a dev server on an isolated worktree database with a Replay (dev) thread, then picked a mode in the composer:

• The DB runtime_mode changed from full-access to approval-required and back, with no message posted.
• The control's label changed once, with no intermediate value.

🤖 Generated with Claude Code (Claude Opus 5.5)

[chatgpt-codex-connector]

Codex Review Summary: ❌ Failed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	❌ Failed 2026-11-12T21:05:49.945890Z We couldn’t complete this review. Comment @codex review to try again.	1d96561	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[chrisohearn]

Substitute review (Claude Opus 5.5), done in place of the hosted Codex reviews, which are blocked by a usage limit. Reviewed 1d96561; efdb4a5 is an empty commit. Verdict: merge after fixes: M1 (the client guard) and M2.

The main change is sound. All 4 browser tests pass at the head and fail against the base hook.

M1. A run can start between the client's idle check and the server applying the change (useComposerSelection.ts:162,168).

• Scenario: Send, then pick a mode before "preparing" reaches the client. Per-thread commands are serialised (threadCommands.ts:78-81), so the set lands just after the turn starts.
• Why it matters: for the owner, the server refuses only when a session has background work (Orchestrator.ts:4308). Claude's check (ClaudeAdapterV2.ts:13024) ignores the turn in progress, so the set is accepted and detaches the live Claude session, which ends the run. Jarvis, MCP or mobile starting a run in that window triggers the same thing.
• Client fix (before merge): also refuse while isSendBusy/isWorking (ChatView.tsx:1418,1470), and when either runtime source shows activity.
• Server fix (follow-up is fine): for owner sets, refuse when a run is active and a session would be detached.

M2. A pending pick is saved in the composer draft, but only in-memory code releases it (:111-132; composerDraftStore.ts:2230,2357).

• Scenario: reload mid-flight, or a draft saved by an older build. The draft is never cleared, the control shows the draft's mode, and the menu ignores re-picking the shown value (ComposerFooterControls.tsx:124).
• Effect: the next send, including a queued send during a run, re-dispatches it (ChatView.tsx:2078 via useComposerSend.ts:1197). That can change the mode mid-run, or undo a lower mode set by MCP, Jarvis or mobile.
• Fix:
  • Hold pending picks in a per-thread map that isn't saved, with a sequence token.
  • Drop runtimeMode from saved drafts of server threads, by migration or on load.
  • Skip the runtime-mode set in persistThreadSettingsForNextTurn during a run.

Low:

• L1. An owner set to the thread's current mode still emits an event and detaches an idle Claude session (Orchestrator.ts:3894-3945, :4286-4298, :4868). The PR triggers this after a refusal revert, on Send while a pick is pending, and when clearing a stuck draft. Server fix: return early when the mode is unchanged.
• L2. A newer pick is matched by value, not by token (:113). With A, then FA, then A, the first refusal clears the third pick. Use a per-thread counter.
• L3. "Caught up" means any change from the old mode (:122), so a revert can briefly show A. If the shell never changes, the subscription at :128 is never removed.
• L4. The local ACTIVE_RUN_STATUSES leaves out "queued" (models.ts:120). Probably fine; add a comment saying why.
• L5. The refusal also applies to Codex, which can switch mode in a live session without ending it. Product call.

Other paths that change the mode mid-run:

• The web shortcut and the policy banner go through the new handler, so they're covered. What's left on the web is M1, and M2 on a queued send.
• Mobile still writes the draft and dispatches on delivery, including queued messages (ThreadSettingsSheet.tsx:1427, threadOutboxDelivery.ts:812-826). Out of scope here; worth a follow-up.

Security: nothing is widened. The client check, server authorisation, the policy ceiling (:15364) and the MCP lower-only rule are unchanged. Note: raising an agent-woken thread such as the Jarvis inbox now applies with no message, so a raise confirmation might be worth adding.

Test gaps:

• Only "running" is covered, not preparing, starting or waiting.
• Nothing sends while a pick is pending.
• The revert test only asserts which commands were dispatched.
• Nothing covers a reload with a saved draft.

🤖 Generated with Claude Code

[chrisohearn]

Substitute re-review (Claude Opus 5.5) of the fixes 1d96561..918d0cc. Verdict: merge after fixing N1.

Earlier findings: M1 (client and server), M2, L1, L2, L3 and L4 are fixed. L5 stays as a product call; the client comment says "Claude", but the client refusal applies to every provider. Tests: 9 browser tests, 182 runtimeLayer tests and 184 related server tests pass. Both halves of the new server test fail without their fix.

N1 (Medium, blocking): a mobile message sent mid-run with a different mode gets stuck permanently.

• Where: the mid-run refusal (Orchestrator.ts:4313-4320) goes through the receipt catch (:15222-15258), which records a rejected receipt.
• Why it sticks: mobile resends the setting under the same command id, ${message.commandId}:runtime-mode (threadOutboxDelivery.ts:202, :812-827), and retries on failure. The server checks the receipt first (:15175), so every retry gets OrchestratorCommandPreviouslyRejectedError, even after the run ends. The outbox delivers one message at a time, so the message and everything queued behind it never go out.
• Fix (server only, no contract change): skip commitRejectedCommand for this refusal, as the catch already does for ceiling refusals. Keep OrchestratorDispatchError with an exported reason constant. Consider doing the same for the background-work refusal at :4326.
• Test: add a runtimeLayer case: refused mid-run, the run ends, then the same command id succeeds.

N2 (info): the nightly desktop app still sends the mode with its next message, using a random command id. If its draft mode differs from the thread's, sends during a Claude run now fail with the server's reason and restore the composer text. Before this PR, the send ended the run.

N3 (low): runtimeLayer.test.ts:3089 covers two behaviours in one case; split it.

Confirmed correct:

• The early return runs after the MCP block, so MCP's lower-only rule is unchanged.
• A same-mode replay succeeds.
• Failover in feat(server): fail a run over to the fallback model when its account fails before any work #68 is unaffected, because it never sends thread.runtime-mode.set.
• No contract, client-runtime or mobile files change.
• Add a comment tying the zero-event allowlist entry to the early return.

🤖 Generated with Claude Code