Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

feat(grok): let a t3-started Grok session run with only the MCP servers t3 declares

Open
  • Is something wrong?
#12,914 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
api, backend, security

Research direction

Start at t3's Grok ACP session/new launch path and trace how the declared mcpServers reach the Grok CLI. Compare the isolated-config-root option with documenting inherited user servers, then verify that a session exposes only the declared servers or that clients can fail closed when it cannot be scoped.

Written by the indexing model from the issue text.

Description

documentation enhancement upstream via-triage
What I'm building

An external orchestrator that starts t3 threads for automated work. Some of those threads
must run with a narrow MCP surface: a worker that reaches exactly one server and provably
not the operator's others — production database servers among them.

Problem

For Claude Code, t3 passes the server set per process (--mcp-config <inline JSON>), and
Claude Code additionally offers --strict-mcp-config to suppress inherited configuration.
For Codex, t3 passes -c mcp_servers.<name>..... For Grok there is no equivalent: t3 starts
the session over ACP and session/new carries mcpServers, but the Grok CLI (1.0.40)
admits that list on top of what it already has (admit_client_mcp_servers) instead of
substituting it.

Everything else in the Grok CLI that looks like an answer is not one: a project-level
.grok/config.toml replaces entries by name only, disabled_mcp_servers is a user-layer
key, and there is no --strict-mcp-config equivalent.

Net effect: a Grok session started by t3 inherits the user's full MCP server set, including
servers imported through [compat.claude] / [compat.cursor]. A client can neither scope
that session nor verify that it is scoped.

Workaround, and why it is not enough

[compat.claude] mcps = false + [compat.cursor] mcps = false in ~/.grok/config.toml.
Verified at both layers: config (every compat-imported server disabled) and live session
(connected set becomes t3-code and nothing else). That is acceptable on a machine
dedicated to t3, but it is machine-global rather than per session, and it disables the
compat import for anyone who also uses Grok interactively.

Ask

Either (a) spawn Grok with an isolated config root — a t3-owned GROK_HOME — so the session
sees only what t3 declares, or (b) if the strictness has to come from the Grok CLI itself,
document that t3-started Grok sessions inherit user-level MCP servers, so clients that need
a scoped session can fail closed instead of assuming.

Dominant language
TypeScript
Stars
24.8k
Forks
6.4k
Avg merge
7h 58m
Merged PRs (30d)
258

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pingdotgg/t3code

All issues in pingdotgg/t3code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.