Pass `T3CODE_THREAD_ID` to Grok (ACP) harness processes, as for Claude #34024

Before submitting#

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area#

apps/server

Steps to reproduce#

1. Register a stdio MCP server in ~/.grok/config.toml that logs os.environ.get("T3CODE_THREAD_ID").
2. Start two Grok threads in one project (Grok driver, grok agent stdio over ACP).
3. Call the tool in each thread. Also run echo $T3CODE_THREAD_ID from a Grok shell.

Expected behavior#

We run third-party MCP servers next to T3's own, registered in each harness's own config. Under the Claude driver, every tool call's server process sees T3CODE_THREAD_ID in its environment, so a server can tell which T3 thread is calling without trusting the agent's word.

Expected the same under the Grok driver: set T3CODE_THREAD_ID (and the other thread vars the Claude driver sets) in the environment of the Grok process T3 spawns per thread, or document another stable way for an MCP server to learn the calling thread.

Actual behavior#

Under the Grok driver the variable is not set: both the MCP server's env value and echo $T3CODE_THREAD_ID from a Grok shell are empty, while GROK_OAUTH2_REFERRER=t3code is present. With two Grok threads open, a server cannot tell them apart.

Possibly the same gap as #28542 (Codex delegated children), here for Grok.

Impact#

Minor bug or occasional failure

Version or commit#

v0.1.7 and v0.1.8

Environment#

Linux, t3 serve; Grok provider (grok agent stdio, ACP), compared with the Claude provider on the same install.

Logs or stack traces#

Screenshots, recordings, or supporting files#

No response

Workaround#

No response