Expose thread/project management actions in the t3 CLI

[dmitryrechkin]

Use case

I run a multi-agent dev board on top of T3 Code: agents work backlog tickets as a sprint of parallel Jira threads, and a scripted board manager orchestrates them — launch, message, read, settle. The launch/read/send loop is already script-first via t3 thread start/send/list/show, which is excellent.

What stops a fully scripted loop is that a few board-critical moves can only be made by a running agent through the orchestrator MCP tools, so every mechanical action becomes "a model does it".

Gap table

Verified against the source at pingdotgg/t3code@80a2351f — every backing tool already exists:

Scripted need	MCP tool that already exists	CLI today
Settle / unsettle / archive threads in a sweep	t3_thread_organize	none
Interrupt or restart a hung thread	t3_thread_send mode restart / t3_thread_interrupt	none
Switch a rate-limited thread's model	t3_thread_configure	none
Wait on an existing run with a deadline	t3_thread_wait	only via start/send --wait
project list --json	t3_project_list	no list subcommand
Cancel a timed-out task	task_cancel	none
Find threads by branch	t3_thread_search	no branch filter on thread list

Proposal

Thin CLI wrappers over these existing tools, in the style of the current thread subcommands — same withThreadTools plumbing (the CLI already signs in as a short-lived MCP client of the running server), same --json flags and error exit codes (ThreadNeedsInputError → exit 2, etc.). No server changes needed.

Example shapes:

t3 thread organize <thread> settle | unsettle | archive | unarchive | pin | snooze [--snoozed-until <iso>]
t3 thread interrupt <thread> [--stop] [--reason <text>]
t3 thread configure <thread> [--provider <id> --model <slug>]   # no flags = print current model/modes
t3 project list [--json]

With organize, interrupt, configure and project list alone, the whole orchestration loop (launch → wait → settle → switch model → restart a hung thread) runs script-only, and agents are left to do actual work instead of meta-calls.

The board works today: scripts read state with list/show, and our own agents reach in through MCP to settle and restart. It just means one extra model turn per mechanical move, which is slow and wastes tokens.

Happy to provide more detail on the use case or help with a PR if maintainers approve this direction.

[dmitryrechkin]

Second part, if it helps make the case: I also prototyped a generic escape hatch so scripts do not need a dedicated command per tool.

t3 mcp list --filter thread          # name + description, --json adds each input schema
t3 mcp call t3_project_list '{"limit": 2}'

It leans on tools/list from the MCP endpoint the CLI already signs in to, so it needs no new server surface — just exposing the session's tool list and calling tools/call with raw arguments. With this, any tool the server already exposes is scriptable, and the commands in the table above become ergonomics rather than requirements.

Same fork, separate branch: feat/cli-mcp-tools on dmitryrechkin/t3code.

[t3dotgg]

Note

🤖 GPT-6.1 Terra [1m] responding on behalf of Theo

Closing as a duplicate of the earlier CLI discussion, where you already consolidated the management commands and generic MCP escape hatch. #27428 comment