feat(mcp): answer delegated user-input requests

[juliusmarminge]

Problem

App-owned delegated children can pause for structured user input, but their parent agent has no scoped MCP read or response path. A generic runtime-request tool would also risk exposing approval decisions or unrelated provider requests.

Change

• Add bounded t3_pending_request_list and exact t3_pending_request_read tools for structured user-input questions on direct app-owned delegated children.
• Add t3_pending_request_respond, which accepts answers keyed by every question ID and dispatches the existing V2 runtime-request.respond command with answers only.
• Preserve exact child/project authority, live provider response capability, durable receipts, stable retry identity, and accepted-overlap replay behavior.
• Enforce captured and fresh caller runtime/interaction ceilings inside deterministic caller/child dispatch locks.
• Register production HTTP discovery, Claude read-only parity for list/read, capability discovery, presentation labels, and user/internals documentation.

Behavior

Read paths are non-mutating and never list approval requests. Stable identity cursors survive resolved prior pages and task reordering; each page caps both returned requests and child projections inspected. Oversized provider question payloads remain discoverable with exact request IDs but are explicitly unavailable and never partially answerable. Respond supports text, numeric, boolean, and bounded multiple-choice answers while rejecting provider-native or unrelated children, non-user-input kinds, stale requests, ended provider sessions, incomplete answer maps, oversized payloads, and mode escalation. Accepted retries reload durable state and return the original receipt without invoking the provider twice.

Validation

• Real managed-provider MCP/V2 integration: a delegated Codex child emits a durable question, list/read discover it, fresh caller-mode enforcement rejects a downgrade, the live adapter receives answers only, and exact-key retry replays the receipt.
• Focused service coverage for stable pagination under mutation, bounded empty scans, deleted-child continuation, storage-error classification, oversized payload handling, scope, stale/non-resumable requests, mode ceilings, accepted-overlap reload, and durable replay.
• Production HTTP tools/list root-object schemas and annotations; Claude read-only allowlist parity.
• 104 focused tests passed across contracts, MCP, presentation, registration, provider allowlist, and real orchestration integration.
• Contracts, shared, and server typechecks; targeted lint, formatting, and diff checks.

Dependency

Standalone sibling on immutable base agents/mcp-controls/base-490318a at 490318afa505d3d033295eca12d7e62b4b922725; independent of project, queue, attachment, and conversation stacks. A one-PR standalone has no native GitHub stack object.

Implemented by GPT-5.6-Sol via Codex in T3 Code.

Note

Add PendingRequestMcpService to answer delegated user-input requests

• Adds PendingRequestMcpService exposing list, read, and respond via three new MCP tools registered in McpHttpServer.ts; respond is idempotent, replays accepted receipts without re-dispatch, and applies the caller's runtime/interaction mode ceilings through a new optional policyCeiling on runtime-request.respond.
• Orchestrator gains getCommandReceipt and enforceRuntimeRequestPolicyCeiling in Orchestrator.ts; inline mode ranking in OrchestratorMcpService is replaced by shared helpers in McpModeCeilings.ts.
• Behavioral Change: dispatchLockKeys now locks both the target threadId and callerThreadId when policyCeiling is present on runtime-request.respond, altering lock scope and acquisition for that dispatch path.

^{Macroscope summarized 88e4840.}

---

Note

High Risk
Touches orchestration dispatch, cross-thread locking, and permission ceilings on runtime-request responses—security-sensitive paths where incorrect enforcement could allow privilege escalation or unauthorized answers on child threads.

Overview
Adds a pending-request MCP toolkit so parent agents can discover and answer structured user-input questions on direct app-owned delegated children, without exposing approval flows or unrelated threads.

t3_pending_request_list, t3_pending_request_read, and t3_pending_request_respond are wired through PendingRequestMcpService, registered on the HTTP MCP server, and included in orchestrator capability discovery (delegatedUserInputRequests). List/read are bounded (cursor pagination, capped child projection scans, oversized payloads marked too_large and non-answerable). Respond dispatches V2 runtime-request.respond with answers only, stable clientRequestId / command receipts, and accepted replay without double provider calls.

Orchestration hardening: runtime-request.respond gains optional policyCeiling; the orchestrator enforces caller ownership, project scope, and runtime/interaction mode ceilings at commit time, and locks both caller and child threads when a ceiling is present. Shared McpModeCeilings replaces duplicated rank checks in orchestrator MCP code. getCommandReceipt and dispatch replayed are exposed through thread management for idempotent respond paths.

Contracts, user/docs, Claude read-only allowlist (list/read), and integration/service tests cover the new surface.

^{Reviewed by Cursor Bugbot for commit 88e4840. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8d148b76-4c5a-49cf-b678-d65900b5ea0e

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Thread transfer impact

⚠️ The latest CI run did not produce a thread transfer result for 88e4840.

This comment will update automatically after the next completed run.

[macroscopeapp]

Reviewed the new PendingRequestMcpService and its call sites against the Effect service conventions. Service definition (inline Context.Service interface, make acquiring ThreadManagementService/Crypto from the environment, export const layer), namespace imports, toolkit wiring, and Foo["Service"] usage all look right. Two findings on the error-translation helpers.

^{Posted via Macroscope — Effect Service Conventions}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

^{Reviewed by Cursor Bugbot for commit f757189. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds three production MCP tools and a new delegated-response workflow, including durable command replay and shared orchestration locking and policy-ceiling changes. The new user-facing capability and cross-component runtime impact exceed a small isolated change and warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

One finding: the child-projection failure classifier discards a statically known tagged error union. The previously flagged dispatchFailure typing is now resolved.

^{Posted via Macroscope — Effect Service Conventions}