Let an Auto thread send to a Full access thread after the user approves that one message

[pjmuller]

What I'm building

A dispatcher thread (runtime mode auto) routes new requests to the existing thread that owns each task. Some owners run in full-access because their user chose that.

Problem

t3_thread_send from the dispatcher to such an owner fails, as designed:

OrchestratorMcpFailure runtime_mode_escalation_denied:
Child runtime mode full-access is broader than parent mode auto.

The ceiling is right: an Auto agent must not start Full Access work by itself. But the only ways to get the message through today are manual and lossy:

• the user copies the message into the owner by hand, or
• the user raises the dispatcher to Full Access for a turn (on Claude this restarts the session and kills in-session background work, [Bug]: Runtime-mode, instance and worktree changes detach the Claude session and kill live subagents without the background-work check #16000), or
• the user lowers the owner to Auto, which changes how the owner's own work runs.

No MCP tool lets the agent ask the user for this one delivery. So agents are tempted to work around the ceiling: spawn a duplicate Auto thread, or route through an outside OAuth client with a higher ceiling.

Ask

A server-owned approval for a single continuation:

1. t3_thread_send with a broader-mode target and requestApproval: true (or a new t3_thread_send_request) does not deliver. Instead it records a pending request bound to {callerThreadId, targetThreadId, message, attachments, mode, clientRequestId} and returns pendingApproval.
2. The caller's row shows an approval card: target title, target modes vs caller modes, the full message. Approve / Deny. No agent can answer it (same as provider approvals today).
3. On approve, the server re-checks the target (exists, not deleted, same modes, still sendable), then delivers once under the target's existing modes. Neither thread's stored mode changes. Active target → queue, unless the request asked for steer.
4. The result is visible to the caller (t3_pending_request_read or a wake): delivered {messageId, runId} / denied / expired / target_changed.

Requirements: approval is bound to the payload hash; idempotent by clientRequestId; expires (for example after 24 h); cancellable by the caller; applies to one delivery only, with no blanket grant.

Why not alternatives

• An MCP mode setter (thread.runtime-mode.set) would let an agent change the permissions a user chose. Even a narrowing-only setter can't touch a broader target under the current ceiling, and it changes how the owner runs from then on.
• Relaxing the ceiling for sends removes the protection the ceiling exists for.

Workaround today

Agent preflights t3_thread_configuration on both threads, writes the continuation to a file and asks the user to paste Read and execute /abs/continuation.md in the owner thread.

Related

• feat: allow a turn to preserve the thread's current runtime mode #12913 (turns preserving the thread's runtime mode)
• [Bug]: Runtime-mode, instance and worktree changes detach the Claude session and kill live subagents without the background-work check #16000 (a runtime-mode change restarts the Claude session)
• Let a thread message threads in other projects, with a grant the user sets #13888 (user-set grants for cross-project sends: same "only the user can widen it" principle)

Observed on T3 Code 0.1.1 (macOS).