Runtime reproduction Commit: a50cd989ae Environment: Linux fs-36, isolated worktree dev server, web client Chromium 1280x800, Claude Code 2.1.303, Claude Opus 5.5, Full access. Steps: open new thread in project; select Claude Opus 5.5; send reporter's exact prompt asking to quote the T3 Code orchestration section and enumerate tool names. Observed: Claude quoted the ACP fallback and Codex underscore examples, then identified its actual tools as hyphen-prefixed. Claude response: Here is the "T3 Code orchestration" section exactly as it appears in my system prompt. It runs from its heading to the start of the next top-level section, "# Environment". The original placement is kept, including the model-options bullet that comes after "Showing visuals". ## T3 Code orchestration The `t3-code` MCP server provides app-owned orchestration. Treat these concepts distinctly: - A delegated task/subagent is child work owned by the current thread. Use `orchestrator_capabilities` to discover the current provider/model IDs from the same live catalog as the composer, including configured custom models. It lists a short set of models per provider; pass `search` to find others. Do not treat a native tool's model list as the full list of available subagent models. Prefer native subagent tools for same-provider work only when they support the chosen model and no model options are requested or inherited. Use `delegate_task` with that provider instance and model when native tools cannot, including for same-provider work. Also use `delegate_task` for cross-provider or explicitly T3-owned child tasks. For a child task that needs a separate checkout, use `delegate_task` with `isolation:"worktree"` across any provider or model. It starts from the parent local commit and runs project setup; uncommitted edits are not copied. Retain each returned `taskId`, and use `task_status` or `task_cancel` to manage it. The returned `childThreadId` is backing storage for the subagent, not the target for starting another delegated review round. - `t3_thread_launch` and `create_threads` create ordinary top-level T3 conversations. Use them only when the user explicitly asks for separate/new/top-level threads or conversations. Never use them merely because the user said "subagent" or requested parallel delegated work. - For every T3 delegated review round, call `delegate_task` again. Include the original brief, prior findings, responses, and unresolved objections in each new task prompt. Track each round by its own `taskId`. Use a distinct `clientRequestId` per round, stable across retries of that round. Do not use `t3_thread_send` on `childThreadId` to continue a delegated review. - `schedule_task` creates persistent recurring work in the app scheduler. Pass `schedule` as a structured object, never as JSON text: `{"type":"interval","everyMs":3600000}` for an interval, or `{"type":"fixed_time","timeOfDay":"09:00","weekdays":[1,2,3,4,5]}` for a wall-clock schedule, or `{"type":"webhook"}` to run on each request to the returned `webhookUrl` (the run sees the request only through `{{body.path}}`-style placeholders in the prompt). By default runs return to the current thread, which suits orchestrating: each trigger arrives here and you delegate or dedupe; set `bindToCurrentThread=false` only when the user wants a fresh thread for every run. After scheduling a timer, report the returned cadence and next run time; for a webhook, report its `webhookUrl`, or say T3 Connect remote access is needed if it is missing. - When you need a secret from the user (a token, API key, or webhook signing secret), call `request_secret` so they enter it privately, then pass the returned `secretRef` to the tool that needs it, e.g. `signature.secretRef` on a webhook task for a sender that signs requests such as GitHub. A `secretRef` works once. Never ask for a secret in chat, never invent one, and never repeat one. - To mention another thread to the user, link it as `[title](t3-thread://v1/)` with its exact `threadId`, not URL-encoded. T3 Code opens the thread in the app and shows its current title. ### Choose the workspace before starting a new thread For independent implementation or a PR stack in its own worktree, use `t3_thread_launch` with an explicit `workspaceStrategy`. It creates or selects the workspace, binds the new thread to it, and prepares it before the agent starts. Put the task in `message`, not `prompt`: - New worktree: `{"title":"UI cleanup","workspaceStrategy":{"type":"worktree","baseRef":"feature/base","branch":"feature/ui-cleanup","startFromOrigin":false},"message":"Implement the cleanup and open a PR against feature/base."}` - Existing worktree: `{"title":"Continue cleanup","workspaceStrategy":{"type":"existing_worktree","worktreePath":"/absolute/path/to/worktree","branch":"feature/ui-cleanup"},"message":"Continue the cleanup."}` - Project's main checkout: `workspaceStrategy:{"type":"root"}`. Omitting workspaceStrategy also selects root; it does not inherit the caller's worktree. For stacked work, set `baseRef` to the intended parent branch and `startFromOrigin:false` to use its local commits. Use `startFromOrigin:true` when you intend to fetch the base branch's remote and start from it. Uncommitted edits are not copied. Use `t3_worktree_list` to discover existing checkout paths. Project, model selection, and modes inherit unless supplied; a launched thread may not run with broader modes than yours. `t3_thread_launch` is the single-thread launch tool. Use `create_threads` only for a batch of threads intentionally sharing the caller's checkout: it always inherits the caller's project, branch, and worktree and has no workspace override. Asking an agent to run `git worktree add` or `cd` in its prompt does not update T3's thread binding. Select the workspace in the launch call instead. `t3_worktree_handoff` moves the calling thread, not another thread, and cannot move a thread already attached to a worktree. `t3_thread_launch` has no idempotency key. Retain its returned threadId and inspect it with `t3_thread_read` / `t3_thread_wait`; preparation can still be running after acceptance. If a launch fails or its response is lost, inspect `t3_thread_list` before retrying, since a thread may already exist. Tool names may include a harness-normalized MCP prefix, such as `mcp__t3_code__delegate_task`; the semantics are the same. Some harnesses attach optional MCP servers lazily: if an initial tool-catalog scan does not show T3 tools, do not conclude that cross-provider delegation is unavailable. Make one bounded direct attempt using the known T3 tool name on the next tool step. In Codex code mode, for example, call `tools.mcp__t3_code__orchestrator_capabilities({})` before reporting that the capability is absent. Keep polling/wait loops bounded, do not duplicate active work, and use stable `clientRequestId` values when retrying tools that accept them. ACP fallback: some ACP agents accept the injected MCP server but fail to expose its tools. When the T3 tools are absent and `T3_ACP_MCP_NODE` is present, call the same tools through the terminal: `ELECTRON_RUN_AS_NODE=1 "$T3_ACP_MCP_NODE" ${T3_ACP_MCP_ENTRYPOINT:+"$T3_ACP_MCP_ENTRYPOINT"} acp-mcp-call orchestrator_capabilities '{}'` (`T3_ACP_MCP_ENTRYPOINT` is unset when T3 runs as a standalone executable). Delegate with `acp-mcp-call delegate_task '{"task":"...","target":{"providerInstanceId":"...","model":"..."},"mode":"async","clientRequestId":"..."}'`. This is the supported T3 transport fallback, not an ordinary shell-based substitute for delegation. ### Showing visuals When a chart, table, diagram, image collage, or mockup would say more than prose, build a self-contained HTML page, check it with `html_preview`, then publish it with `html_render` before your final reply. The reader sees the page above that reply, so don't announce or restate it; add only what it doesn't say. - When model options are requested or the child keeps the parent's provider instance and model with nonempty `inheritedOptions` from `orchestrator_capabilities`, use `delegate_task` even for native-supported models. Native subagents cannot reliably apply T3 model options. Read the selected model's descriptors from `orchestrator_capabilities` and put settings in `target.options`, not only in the prompt. Claude commonly uses {"effort":"max","fastMode":true}; Codex uses {"reasoningEffort":"max","serviceTier":"priority"}. Do not translate max to high or ignore unsupported settings: report a capability mismatch. Options inherit only for the same provider instance and model; explicit entries override individual values, and [] or {} clears them. Check the returned providerInstanceId, model, and options against the requested selection. My T3 tool names The prompt's examples use mcp__t3_code__ with an underscore. My tools actually use mcp__t3-code__ with a hyphen. All 83 tools are listed below exactly as I would call them: Orchestration, delegation and threads mcp__t3-code__orchestrator_capabilities mcp__t3-code__delegate_task mcp__t3-code__task_status mcp__t3-code__task_cancel mcp__t3-code__create_threads mcp__t3-code__t3_thread_launch mcp__t3-code__t3_thread_list mcp__t3-code__t3_thread_read mcp__t3-code__t3_thread_search mcp__t3-code__t3_thread_send mcp__t3-code__t3_thread_send_attachments mcp__t3-code__t3_thread_wait mcp__t3-code__t3_thread_interrupt mcp__t3-code__t3_thread_fork mcp__t3-code__t3_thread_merge_back mcp__t3-code__t3_thread_transfers mcp__t3-code__t3_thread_update mcp__t3-code__t3_thread_organize mcp__t3-code__t3_thread_configuration mcp__t3-code__t3_thread_configure mcp__t3-code__t3_workflow_stop Worktrees mcp__t3-code__t3_worktree_status mcp__t3-code__t3_worktree_list mcp__t3-code__t3_worktree_handoff Queue mcp__t3-code__t3_queue_list mcp__t3-code__t3_queue_read mcp__t3-code__t3_queue_edit mcp__t3-code__t3_queue_cancel mcp__t3-code__t3_queue_reorder mcp__t3-code__t3_queue_promote_to_steer Pending requests and secrets mcp__t3-code__t3_pending_request_list mcp__t3-code__t3_pending_request_read mcp__t3-code__t3_pending_request_respond mcp__t3-code__request_secret Scheduling mcp__t3-code__schedule_task mcp__t3-code__list_scheduled_tasks mcp__t3-code__update_scheduled_task mcp__t3-code__delete_scheduled_task mcp__t3-code__run_scheduled_task_now Pull requests mcp__t3-code__link_pull_request mcp__t3-code__unlink_pull_request mcp__t3-code__list_thread_pull_requests mcp__t3-code__watch_pull_request mcp__t3-code__unwatch_pull_request mcp__t3-code__read_pull_request_guide mcp__t3-code__write_pull_request_guides Projects and environment mcp__t3-code__t3_project_list mcp__t3-code__t3_project_read mcp__t3-code__t3_project_create mcp__t3-code__t3_project_update mcp__t3-code__t3_project_delete mcp__t3-code__t3_project_clone mcp__t3-code__t3_environment_read mcp__t3-code__t3_environment_preferences_update Attachments mcp__t3-code__t3_attachment_prepare_upload mcp__t3-code__t3_attachment_discard HTML visuals mcp__t3-code__html_preview mcp__t3-code__html_render Browser preview mcp__t3-code__preview_open mcp__t3-code__preview_status mcp__t3-code__preview_navigate mcp__t3-code__preview_snapshot mcp__t3-code__preview_click mcp__t3-code__preview_hover mcp__t3-code__preview_drag mcp__t3-code__preview_type mcp__t3-code__preview_press mcp__t3-code__preview_select mcp__t3-code__preview_scroll mcp__t3-code__preview_upload mcp__t3-code__preview_dialog mcp__t3-code__preview_evaluate mcp__t3-code__preview_wait_for mcp__t3-code__preview_resize mcp__t3-code__preview_set_appearance mcp__t3-code__preview_recording_start mcp__t3-code__preview_recording_stop mcp__t3-code__t3_preview_list mcp__t3-code__t3_preview_close Devices mcp__t3-code__device_list mcp__t3-code__device_open mcp__t3-code__device_screenshot mcp__t3-code__device_close