Environment-level MCP servers (and later rules/skills) shared by every provider and account

[x56sandmanx]

Problem
When you run more than one provider account in T3 Code, each account keeps its own MCP config. Adding a server like Linear means setting it up again per account. Rules and skills have the same problem.

Idea
Let T3 Code own a list of MCP servers per environment and attach them to every provider session, next to the t3-code server it already injects. Every adapter already has a per-session MCP hook, so this extends a list that already exists rather than adding new machinery:

• Claude: SDK mcpServers
• Codex: -c mcp_servers.* overrides
• Cursor, Grok and Antigravity: ACP session/new
• OpenCode: mcp.add

Details:

• Where: Settings → Providers → MCP servers. Command (stdio) or URL (streamable HTTP) servers, an on/off switch, and all projects or specific projects.
• Secrets: sensitive env vars and headers use the existing secret-store and redaction path, like provider environment secrets.
• Remote: servers resolve on the environment that runs the agent, so it behaves the same over LAN, Tailscale and Connect.
• Not included yet: OAuth. Servers that need a browser login work through mcp-remote or a bearer token.

Status
I have a working prototype on a local branch that I use on my own build. It's about 1.3k lines including tests and a user doc, so I'm not opening a PR. If this direction fits, I'm happy to split it into small PRs (contract + settings, server injection, settings UI), or you can build it your own way.

Rules and skills would be natural follow-ups. Rules can reuse the existing runtime-instructions append. Skills are harder, because each CLI only finds them by scanning its own folders.

[narcisoaf]

I implemented this, following the design above: Settings → Integrations → Shared MCP servers (plus a mobile screen). Add a server once (name, URL, optional headers), and every new agent session on that environment gets it next to t3-code: Claude, Codex, Cursor, OpenCode 1/2, Pi, and ACP agents (via the existing stdio bridge). Header values use the secret store. Each server has an on/off switch and a Test connection action. It never reads or rewrites the agents' own config files.

PR: #16466

[goleary]

+1, and OAuth is the main thing I'd need. I run four provider accounts (Claude and Codex, personal and work), and the one server I want everywhere is a hosted MCP gateway that uses OAuth (executor.sh). Even with the server added globally in each CLI, I still have to sign in separately in each account's config folder, and Claude has no command-line sign-in, so that means an interactive /mcp session per account. If T3 handled the OAuth for its own MCP servers (sign in once per environment, then share the token across provider sessions), the cross-provider setup would actually be one step. Pairs well with #11821's sign-in/reconnect controls.

[narcisoaf]

Yes in fact I added that as well in my PR #16466 (there are the screenshots in the PR body) so that you can add and manage all MCP servers (also that require oauth) on t3 code without having to use an external mcp proxy.
Is that what you wanted? or you want to keep using the mcp gateway?

[goleary]

i will keep using a mcp gateway so that i have portability and can continue using other tools if it suits me.

[raiomarco]

+1 to this direction. #16466 covers the MCP half at environment level. Below is data and a use case for the "later rules/skills" part, plus project scope and subagents. It also connects with #15823 (skill manager) and #14554 (agent roles).

What actually reaches a T3 session today

We opened one session per provider in the same repo, inside a git worktree T3 created (Oct 11 2026). Each agent reported what was in its context at startup, before reading any file. The repo ships the config files every provider documents.

	Claude	Codex	Grok	Antigravity
AGENTS.md	whole (via CLAUDE.md)	truncated at 32,768 B	not loaded (folder not trusted)	not loaded
Project rules	3 of 3 always-on	only via AGENTS.md	0	0
Project subagents	12	0 (project config not trusted)	12 (via Claude compat)	0
Project MCP	3 of 4	0	4, but from the user's ~/.cursor/mcp.json, not the repo	0 (only t3-code)

Versions: Codex CLI 0.162.1, Grok Build 1.0.50, Antigravity ACP server 1.3.0 (built 2026-09-29), T3 Code nightly 0.0.46 (2026-10-10).

Two causes are upstream:

• Folder trust (Codex and Grok). Both gate project config on it, and each T3 worktree is a new folder. Codex does resolve a worktree to the main repo root, so one [projects."<repo>"] entry covers all worktrees; Grok trusts the git root.
• Antigravity's ACP server loads no rule files at all ([Bug]: Antigravity sessions load no AGENTS.md/GEMINI.md rules (global or workspace), unlike Claude and Codex #15283) and only takes MCP from session/new (Allow user-configured MCP servers in ACP sessions (Antigravity & ACP providers) #13117).

Users work around each of these per provider and per machine. The same injection seam #16466 uses could make it uniform.

Suggested extension

1. Project scope next to environment scope

• Declare the project half in t3.json, which already holds project settings and actions, or in a .t3/ folder for Markdown content.
• Resolve both halves with the existing order: project override → environment → t3.json → default.

2. Rules

• Support always-on and path-scoped (glob) rules.
• Deliver them through the runtime-instructions append where the provider supports it, and as a first-message preamble for ACP providers ([Bug]: Antigravity sessions load no AGENTS.md/GEMINI.md rules (global or workspace), unlike Claude and Codex #15283).
• Path-scoped rules can be listed with their globs so the agent loads them on demand. That keeps the always-loaded size small.

3. Subagents

• Write one definition: name, description, model hint, tool allow-list and body.
• Map it to each provider's native format where one exists (Claude, Codex, Cursor, OpenCode, Grok).
• Elsewhere, expose it as a delegate_task preset.

4. Skills

• Keep the provider-agnostic .agents/skills discovery ([Feature]: Discover repo-local .agents/skills (Agent Skills standard) provider-agnostically, not per provider #5492) and the skill manager (Skill manager: view, add, edit, and link skills across every harness #15823) in the same model, with user-level roots.

5. Inspect

• Add a per-thread view of what the session received: rules with byte sizes, MCP servers, subagents and skills.
• We had to get the table above by asking each agent. Hidden caps like Codex's 32 KiB truncation are invisible otherwise.

6. Optional "materialize"

• Export to each provider's own files for people who also run the CLIs outside T3, with a drift check.
• Injection stays the default, because it sidesteps folder trust and per-worktree paths.

Prior art

We do the materialize half today with a script. One source in the repo holds rules (body plus load metadata), subagents, skills and an MCP list. A generator writes the Claude, Codex, Cursor, OpenCode, Grok and Antigravity formats. A verifier fails CI on:

• hand-edited generated files and orphans;
• an always-loaded set above 60,000 B;
• AGENTS.md above Codex's 32,768 B;
• an MCP server restricted to some providers without a written reason.

It works, but every new provider needs a new generator and new measurements. And as the table shows, files on disk still don't guarantee what reaches a T3 session. Doing this once in T3 would cover every provider it adds.

[NK-Works]

Following up from #18637 (closed as dup) — this thread is the right home for the MCP half. Strong support for the env-level list injected per-session via existing adapter hooks.

Two additions from our spec, for consideration in the prototype:

• Secrets shape-only + precedence: sync command/args/URL/header names, never values; values stay per-harness/per-machine via the existing secret-store + redaction path, with a missing-secret indicator. Precedence per-project > per-user > global so per-project MCP (Per-project MCP #276/Per-project MCP #277: Supabase Acct oxc stack #1 on Proj oxc stack #1, Acct Add open-in-editor feature with Cmd+O shortcut #2 on Proj Add open-in-editor feature with Cmd+O shortcut #2) works without key leakage across projects.
• Fail-closed + rollback: incompatible mcpServers / mcp_servers.* / mcp.add fields warn and block rather than drop; every sync shows a diff with backup/rollback, and externally edited harness files need confirm before overwrite. OAuth via mcp-remote/bearer as you already scoped is the right V1 line.

Glad to test the local-branch prototype against these cases if useful.

[MikaMcFlurry]

I implemented a version of this in a fork, as two independent branches:

MCP servers: mika/central-mcp

• New centralMcpServers server setting (stdio {command,args,env} or http {url,headers}, enabled flag; the name t3-code is reserved).
• Claude gets them as query mcpServers next to t3-code; Codex gets mcp_servers.<name> config overrides in codexThreadRuntimeParams. Both read the setting at session start, so the credential and reuse logic in ProviderSessionManager is untouched.
• Settings → Providers → Central MCP servers: add (name + command line or URL), toggle, remove.
• ACP providers are not wired yet.

Skills: mika/central-skills

• A central library in <state>/skills. Claude loads it as an additional directory; Codex homes get marked copies that are synced before probes and sessions, and user-owned skills with the same name always win.
• centralSkills.* RPCs plus agent tools t3_skill_list / t3_skill_install / t3_skill_remove (install from a folder, a git URL including GitHub /tree/<ref>/<path>, or a raw SKILL.md URL). The MCP tool list grows by about 1.1 KB.
• Settings → Providers → Central skills.

Both have unit tests and pass typecheck. Happy to split or reshape into PRs if a maintainer approves the direction.

Written with Claude Opus 5.5 in Claude Code (running in T3 Code).

[dmitryrechkin]

Strong +1, and worth noting two people have already posted implementations in this thread (413n's Settings → Integrations → Shared MCP servers, and MikaMcFlurry's mika/central-mcp branches).

I checked the adapter seams on main@80a2351f to confirm the mapping in the opening post is accurate, with the exact places a registry would plug in:

• Claude: T3 already injects its own server through the same option — claudeMcpQueryOverrides builds mcpServers: { "t3-code": { type: "http", url, headers } } (apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts:1717-1745), and the same session can be updated live via queryRuntime.setMcpServers (:1059). So merging an environment list in is genuinely additive.
• ACP (Cursor, Grok, Muse, Fx): mcpServers is a first-class session option (packages/provider-acp/src/server/AcpSessionRuntime.ts:125, resolved per activation at :2104).
• Codex: -c mcp_servers.* overrides are already generated (today to disable them) in apps/server/src/textGeneration/CodexTextGeneration.ts:45-49.
• Antigravity: its settings file's mcpServers is already merged by apps/server/src/textGeneration/AntigravityTextGeneration.ts:81.
• OpenCode: spawned from its own config (packages/provider-opencode/src/server/adapter.ts), so a generated fragment works.

One addition to the design from our side, because it bites at scale: every enabled server multiplies the tool definitions in every thread's context. We hit this pattern with T3's own 69 tools, and #19190 reports ~83 tools declared per turn on one gateway. So alongside per-project scope, I would include a per-server tool allowlist (or a "declared tools only" toggle) and keep the reserved t3-code name out of the registry, as Mika's branch does.

I run a multi-agent Jira board on T3 and would switch to this the day it lands; happy to test either implementation on macOS/Linux and report against Claude, Codex and ACP, rather than adding a third prototype.

[dmitryrechkin]

A scope proposal that answers the approval question directly: OAuth belongs in the first version, but behind an opt-in proxy, as step 2 of 3.

Why it is not optional: the servers people most want across providers are remote ones with interactive sign-in (Atlassian, Linear-style gateways, executor.sh — see goleary above). Claude only signs in through an interactive /mcp per account folder, and Codex keeps its own mcp-oauth-locks per account, so N accounts means N logins. Nothing at the provider layer can share that token; only T3 can.

Suggested split:

1. Registry + injection (no new workflow). A centralMcpServers setting, stdio or plain-HTTP, on/off, reserved t3-code name, injected next to t3-code in Claude's mcpServers, Codex's mcp_servers.<name> overrides, and ACP session/new. This is the part that is purely additive to what T3 already does.
2. Opt-in OAuth proxy. Per server, "requires sign-in" turns on a T3-local streamable-HTTP proxy that holds the token. Agents get a bearer URL they already understand; T3 does discovery + dynamic client registration + PKCE + refresh, stores the token in the existing secret store, and exposes sign-in and revoke next to the server. Single-operator environments (the common case) get one sign-in for every provider account; the credential is the environment's identity, which should be stated in the UI rather than hidden. Multi-user environments can opt out per server.
3. Ergonomics. Per-project scope, a per-server tool allowlist (tool definitions land in every thread — see [Bug]: Pi sessions on openai-completions gateways declare all ~83 T3 MCP tools on every turn (regression of #16651/#17220) #19190), and mobile parity.

mcp-remote remains the documented interim for step 2 while this is unbuilt.

I can help either way: test, or produce the step-1 slice alone if the proxy is what needs more discussion.

[MikaMcFlurry]

@dmitryrechkin's step 1 matches mika/central-mcp, so I closed the gap it had. It now covers ACP agents as well.

mika/central-mcp (3 commits, rebased on today's main):

• Setting: centralMcpServers, stdio {command, args, env} or HTTP {url, headers}, with an on/off switch. The t3-code name is reserved in the schema.
• Claude: query mcpServers next to t3-code.
• Codex: mcp_servers.<name> overrides in the thread runtime params.
• ACP (Grok, Antigravity, Fx, ACP registry): a Context.Reference in provider-acp that the server fills from settings. sessionMcpServers appends the shared servers to whichever t3-code list the agent gets (ACP, HTTP or stdio). Stdio servers go to every agent. HTTP servers go only to agents that advertise mcpCapabilities.http. Stdio commands are resolved like T3's own spawns, because agents start them without a shell and the schema asks for an absolute path. On Windows, .cmd shims such as npx run through cmd.exe. Every activation path (new, load, resume, fork, MCP re-activation) goes through the same function.
• Freshness: everything is read at session start, so a settings change reaches the next session and ProviderSessionManager reuse is untouched.
• Not included: OAuth (step 2), per-project scope and tool allowlists (step 3), and Cursor (it runs on the SDK path, not ACP).

Tests cover the mapping for each harness, the runtime's session/new payload with and without HTTP support, a shared server named t3-code not replacing T3's own, and Windows command resolution.

@juliusmarminge, the closure of #16466 asked for approval of direction and scope here first. Would step 1 as scoped above be acceptable as one PR? If you'd rather split it (contract + Claude/Codex first, ACP second) or put it behind Labs, I'll shape it that way.

[a-Fig]

+1, with another use case: Murmur, which lets coding agents on different machines in the same repo message each other through git refs. It's a local stdio server (mur mcp), and today mur join writes it into each CLI's own config: Claude Code (claude mcp add --scope user) and Codex (config.toml). In T3 that leaves out OpenCode, Antigravity and the other ACP providers, and a second Claude account only gets it if join runs under that account's CLAUDE_CONFIG_DIR. A shared list would fix all of that at once.

One thing a stdio server in the shared list needs that a hosted one doesn't: knowing who launched it. Murmur delivers each message to the session it's addressed to, so the server has to know which provider and which T3 thread it's serving. Today it works that out per CLI (for Codex it registers mur mcp --agent codex and passes T3CODE_CLI_PATH through env_vars). Since the list is injected per session, T3 could put the provider kind and thread id in a shared stdio server's environment (say T3CODE_PROVIDER and T3CODE_THREAD_ID), and then one entry would serve every provider.

[MikaMcFlurry]

Good point, and easy to support since the list is injected per session. I added it to mika/central-mcp (370eb41). Every shared stdio server now gets:

• T3CODE_PROVIDER: the driver kind (claudeAgent, codex, or the ACP flavor such as grok or antigravity)
• T3CODE_PROVIDER_INSTANCE: the account instance, so two Claude accounts are distinguishable
• T3CODE_THREAD_ID: the T3 thread the session serves

This works the same for Claude, Codex and ACP sessions. A server's own env entries win if they set the same name. HTTP servers aren't covered, since they have no process environment. Headers would be the equivalent there, but I'd keep that out of a first version.

So one mur mcp entry should serve every provider and account. If you try it, I'd like to hear whether Murmur needs anything else per session.

[sycamore-3999]

I strongly support this direction. My concrete case is shared remote MCP with OAuth, and I think OAuth has to be part of the first usable version.

I want to add Figma's remote MCP server (https://mcp.figma.com/mcp) once at the T3 environment level, then have every new provider session use it — Claude, Codex, Cursor/ACP, OpenCode, etc. — without configuring and authenticating separately for each provider or account.

The current per-provider injection approach is not enough for this case. Even if every adapter receives the Figma server, each provider still goes through its own OAuth flow. So the result is still “configure once, sign in N times.”

What I need is the generic infrastructure, not Figma-specific code:

• An environment-level shared MCP registry with enabled/disabled state.
• Remote streamable HTTP servers with T3-managed OAuth.
• One Figma sign-in per environment, with tokens stored in the existing secret store.
• A T3 proxy endpoint injected into every provider session next to t3-code.
• Credentials never exposed in provider argv, environment variables, or logs.
• Sign in / re-authenticate / revoke / test connection controls.
• Clear disclosure that all threads on the environment act as the same Figma account.

For my use case, one environment-level Figma identity is acceptable as long as the UI states it explicitly. Per-user identity forwarding would be nice later, but should not block the single-operator case.

I also agree with keeping t3-code separate and considering a per-server tool allowlist, because every shared server otherwise adds tool definitions to every thread.

Figma is just the concrete example that makes the gap obvious: without a shared OAuth proxy, “add once, use from every provider” is still not achieved.

[MikaMcFlurry]

+1 to the OAuth part, @sycamore-3999. My case is the same problem at a larger scale: not one server, but the remote connectors I use every day: Gmail, Google Calendar/Drive/Docs/Sheets, GitHub, Slack, Notion, Linear, Vercel, Supabase, Cloudflare, Figma and Canva. I work across three Claude and three Codex accounts plus Grok and Antigravity, on three linked machines.

Today that means:

• the connectors exist only in Claude threads, and only for the Claude account where each one was signed in;
• Codex, Grok and Antigravity threads have none of them;
• every new account or machine starts at zero.

So "configure once, sign in N times" is optimistic for me: it's closer to "sign in accounts × machines times, and never in some providers".

The stage-1 version I run in my fork (linked above) shows where the line is. It already shares remote streamable-HTTP servers (url plus static headers) and stdio servers with Claude, Codex and ACP sessions from one settings list. That works for token-in-header servers. It doesn't work for OAuth connectors, because each provider then runs its own sign-in.

Your list matches what would close that gap. T3 already serves t3-code to every session over its own MCP endpoint, so serving the shared remote servers through that same endpoint seems the natural place for T3-held OAuth tokens. Two additions from my side:

• Per-server allowlist, and lazy loading. With a dozen connectors, sending every tool definition into every thread is real context cost. Providers that defer MCP schemas (Claude Code and Codex tool search) help, but T3 shouldn't assume it.
• Linked environments. One sign-in per environment is fine. It would help if a linked machine could use the proxy of the environment that holds the tokens, instead of signing in on every machine.

If a maintainer agrees on the direction, I'd be glad to build the proxy and OAuth part on top of stage 1.

[MikaMcFlurry]

@sycamore-3999 Agreed that OAuth is where "add once" breaks today. Here is how far step 1 in mika/central-mcp gets for your case:

• A remote server is { url, headers }, injected into every provider session next to t3-code. A server that accepts a static bearer token works across Claude, Codex and ACP agents with one entry.
• Figma's remote server wants an interactive OAuth flow, not a static token. Each provider would still sign in on its own, as you describe.

Your proxy shape fits on top of that without changing the provider side:

1. T3 runs the OAuth flow once per environment and keeps the tokens in the server secret store.
2. Sessions get a local t3-mcp-proxy/<server> URL instead of the real one, so credentials never reach argv, env or logs.
3. The proxy adds the token and refreshes it.

Step 1 would ship without OAuth and leave the registry entry shaped so a later auth: { type: "oauth" } slots in. The per-server tool allowlist you mention matters less for Claude and Codex now: both defer MCP tool schemas behind tool search by default. For ACP agents that depends on each agent's client, so it can still help there.

[djgilcrease]

NOTE: This comment was left by gpt-6.1-sol high on behalf of Dj Gilcrease.

I built another runnable option for the environment-owned, per-session approach described here: an external MCP Manager plugin on the proposed plugin host. The plugin proposal update, with screenshots has the source, install steps and verification limits.

It provides environment-wide definitions, project overrides, provider/account-instance switches, and manager-owned OAuth for Streamable HTTP servers. A global OAuth definition can share one connection across inheriting projects/providers; project definitions can instead use separate accounts at the same URL. Tokens stay in the environment's plugin secret store, and providers get private proxy routes. It does not rewrite their config files.

It requires the prototype host fork and is not available in stock T3 Code. The point of the experiment is to let people implement and distribute optional features such as this in their own repositories, while T3 owns a reviewed generic session-injection/permissions contract. This complements the implementations already linked here; it does not imply that maintainers have chosen this design. Design feedback can go to the plugin discussion so that conversation stays together.

[pjacobr]

+1, and adding a concrete use case that I don't think the V1 designs cover yet: multiple accounts of the same service, shared across providers.

I run T3 across several providers and accounts (Claude, Codex, Cursor, Muse Code) and machines. I have multiple Gmail accounts (personal and work), plus Google Calendar, Drive, Slack, Linear, and Notion. Today each of those has to be set up separately in every provider's config, for every account, on every machine. When I switch providers mid-thread, the agent loses access to my connectors.

What I'd love: I sign into each service once in T3 (including more than one Gmail account), and T3 attaches those connections to whichever provider and session runs the thread, next to t3-code. Tokens stay in T3, the agent just sees the tools, ideally with clear account labels (e.g. gmail-work vs gmail-personal).

Even a V1 limited to one environment-level registry would help a lot, as long as the design leaves room for several accounts per service instead of assuming one sign-in per environment. Happy to help test, or contribute once there's a maintainer-approved scope.

[MikaMcFlurry]

@pjacobr Same setup and the same wish here, multiple Gmail accounts included.

Step 1 on my branch (mika/central-mcp) already covers the "several accounts per service" part:

• Every server is a named entry in one environment-level registry, so gmail-work and gmail-personal can sit side by side.
• Each entry is injected next to t3-code into every Claude, Codex and ACP session, so a provider switch mid-thread keeps the tools.
• Header and env values sit in T3's secret store and are masked in the client.

It doesn't do the sign-in yet. Each entry still needs a token or a local server you set up yourself. OAuth is the part this discussion is waiting on maintainers for (#16466 was closed for it), and I'd keep the registry shaped so that an auth block per entry fits later without changing the multi-account model.

If you want to try it, the branch is rebased on current main. Feedback from a Cursor/Muse setup would be useful, since I've mostly run it with Claude and Codex.