[Feature]: Add thread management to CLI for external orchestration #6779

I got some impl as well: https://github.com/tarik02/t3code-cli

Corporate Claude Code installations can have a managed MCP allowlist that rejects T3's localhost MCP endpoint. Users cannot change this policy, so Claude coding works inside T3, but delegation, task status, and browser tools are unavailable.

Is there a supported solution for this environment? Could the t3 CLI expose these operations with automatic binding to the current thread?

+1 from another corporate Claude Code user. Our managed MCP allowlist blocks t3-code, and an admin exception isn't happening, so a CLI mode is the only way T3 orchestration works for us on Claude.

Concrete proposal, from #19236 (closed as a dup of #18635): an opt-in setting on Claude provider instances, "T3 tools: MCP / Terminal". In Terminal mode the adapter skips setMcpServers and puts T3_ACP_MCP_ENDPOINT, T3_ACP_MCP_AUTHORIZATION, T3_ACP_MCP_NODE and T3_ACP_MCP_ENTRYPOINT in the Claude process env, the same way the ACP adapter does now. The agent then calls tools with the existing t3 acp-mcp-call <tool> <json>, so it's already bound to the current thread and uses the same scoped session token. The prompt swaps in terminal calling instructions so the agent doesn't look for MCP tools first.

The tradeoff is that the token ends up in the env where commands the agent runs can read it, which is why I'd keep it opt-in with that spelled out in the setting description. I have a working branch with tests for this if a maintainer is open to the direction. Happy to adjust it to whatever CLI shape you'd prefer.

The t3 thread CLI can list, start, message and read threads for external orchestration. The enterprise Claude request for thread-bound delegation when MCP is restricted already has a dedicated discussion. #22732 thread.ts