Setting to not attach the t3-code MCP server (and its prompt text) to agent sessions

[alberduris]

Note

Written by Claude (Claude Code, Opus 5.5) at my request, and edited and reviewed by me before posting.

Problem

T3 Code attaches its t3-code MCP server to every agent session and appends its own instructions to the system prompt. There is no setting to opt out.

To put things in perspective, on 0.0.45 that is 21 tools plus <runtime_info> and <pull_request_linking>; on main it is about 80 tools plus the orchestration instructions. Ideally, I'd have no extra MCP tools added outside my control.

For me, the injected server and text are noise, and sometimes they conflict with the workflow I already have (my Claude found #15370, which seems to be the PR-watcher version of this).

The only way out today is a Claude Code permissions.deny rule for mcp__t3-code. It hides the tools, but not the prompt text, and it only works for Claude. It's also backwards. Using T3 Code shouldn't require changing Claude Code's own configuration.

Proposal

A setting, global and optionally per provider or per project, that stops T3 Code from attaching the t3-code server to agent sessions (global alone is enough for me). When it is off, neither the server nor any prompt text that describes its tools is sent.

A finer-grained version would be one toggle per toolkit (pull requests, orchestration, worktree, ...), following the existing Agent browser access and Agent device access toggles. To be clear, I don't need this myself; a single global switch works for me.

Tradeoffs

Features that need the server (e.g., PR linking and status, orchestration...) stop working for those threads. But that is the user's explicit choice, and the setting can say so.

Related

• Allow custom PR watchers without conflicting runtime instructions #15370 (opt out of the PR-watching instructions)
• [Bug]: Claude Code threads get T3 instructions meant for other agents #16465 (Claude threads get T3 instructions meant for other agents)
• [Feature]: /mcp view to inspect and control each MCP server #10535 (inspect and control MCP servers from T3 Code)
• [Bug]: With agent browser/device access off, the agent still sees every preview_* and device_* tool #17202 (with agent browser/device access off, the agent still sees the preview_* and device_* tools)

[bheemreddy-samsara]

I’ve noticed differences in how Pi behaves when running through T3 Code versus directly through the Pi CLI. I haven’t isolated the cause, but I’d like a way to compare the two without T3’s additional instructions influencing the session.

Would you be open to an optional UI-only / native Pi mode, where T3 acts as the interface without injecting its own additional prompts, t3-code MCP tools, or orchestration instructions and behavior?

For this use case, I’d want to:

• Keep T3’s chat UI and session display.
• Disable T3-added prompt text and orchestration/tool injection—not just hide the tools while leaving their instructions in context.
• Preserve Pi’s own system prompt, user/project instructions, extensions, skills, and configured tools, as they would apply when running Pi directly.

That last point is the distinction from the broader blank-slate proposal: I’m not asking to remove my native Pi configuration, only T3’s additional layer. I’d accept that features depending on T3’s injected tools would be unavailable in this mode. An opt-in settings flag, with the existing behavior remaining the default, would cover my use case.

[bheemreddy-samsara]

@juliusmarminge can i get some thoughts ?

[szafranski]

A per-provider-instance MCP opt-out would also help generic ACP agents using a local backend with narrower JSON Schema support.

With T3 Code 0.1.0, DeepSeek Harness 0.2.1-rc.2 and local Qwen3.8-27B on TheTom/llama-cpp-turboquant bcb85fc, a fresh T3-owned ACP test failed before any tool execution:

400 Failed to initialize samplers: failed to parse grammar
parse: error parsing grammar: unknown escape at \S

The parser dump points to mcp__t3-code__preview_navigate's nested target.url field. Its URL schema uses isTrimmed(), which contributes this string constraint:

{"type":"string","minLength":1,"maxLength":2048,"pattern":"^\\S[\\s\\S]*\\S$|^\\S$|^$"}

A reduced tool schema containing that field under target: {kind: "url", url: ...} returned HTTP 400. Removing only pattern returned HTTP 200 with a complete DIAGNOSTIC_OK response, fingerprint b1-bcb85fc. Both requests used the same tool name and synthetic message, auto tool choice, thinking disabled and a 16-token output cap. No tool ran.

This is a backend compatibility result on an older fork; current llama.cpp master has not been tested. It gives a concrete use case for the opt-out proposed here, alongside the catalog filtering discussed in #17202. I would like to retain T3 as the frontend for this ACP agent while omitting T3-added MCP tools, and accept losing the features that depend on them.