Skip to content

MCP bearer token passed via environment is captured in systemd-coredump journal entries on provider crashes #12031

Open
Open
MCP bearer token passed via environment is captured in systemd-coredump journal entries on provider crashes#12031
Labels
acceptedfeature request acceptedbugSomething is broken or behaving incorrectly.codexvia-triageFiled through npx t3 triage

Description

@john-e-west
john-e-west
opened on Sep 16, 2026

Summary

T3_MCP_BEARER_TOKEN is passed to spawned provider processes through the
environment. On Linux, systemd-coredump records the entire environment of
any process that dumps core into the systemd journal as COREDUMP_ENVIRON,
in plaintext. So every provider crash writes that session's MCP bearer token to
a log readable by the account the providers run as.

Requesting a file- or fd-based alternative, in line with the --bootstrap-fd
mechanism this project already has.

Where it happens

From the shipped bundle:

environment: {
  ...(options?.environment ?? process.env),
  T3_MCP_BEARER_TOKEN: mcpSession.authorizationHeader.replace(/^Bearer\s+/, "")
}

paired with the Codex MCP client config:

-c 'mcp_servers.t3-code.bearer_token_env_var="T3_MCP_BEARER_TOKEN"'

Measured impact on one host

Every core dump over a two-week window on a machine running a provider fleet:

dumps: 18 | with full environment recorded: 18 | carrying a secret-shaped value: 17

COREDUMP_ENVIRON is readable by root, the systemd-journal group, and —
via the journal directory ACL — the user the providers run as. Where multiple
provider sessions share one Unix account, any session that can run
journalctl can read the MCP token of any other session that has crashed.

journalctl --output=json omits the field by default because it is large;
--all reveals it. That makes the exposure easy to miss entirely.

Scope, stated honestly

mcpSession.authorizationHeader reads as a per-session token, and that
matches observation: a token recovered from a dump returned 401 against both
/mcp and /api/orchestration/snapshot after its session ended, while a freshly
minted token returned 200 on the same route. So this is not a long-lived
credential leak.

The exposure is therefore bounded to the lifetime of the session whose provider
crashed — but within that window it is a usable token sitting in a world-of-the-
account-readable log, and provider crashes are not rare on a busy host.

I would call this moderate rather than critical, and I would rather describe it
accurately than inflate it.

Why the environment is the wrong channel specifically

Not a general "env vars are bad" argument — this is a concrete Linux behaviour:

  • /proc/<pid>/environ is readable for the lifetime of the process.
  • systemd-coredump persists the whole block on any crash, and it outlives the
    core file    , since Storage= controls the core, not the journal metadata.
  • coredump.conf on systemd 261 exposes only Storage, ProcessSizeMax,
    SizeMax, ExternalSizeMax, MaxUse, Compress, EnterNamespace,
    CoredumpReceive — there is no way for an operator to exclude that field.

So a deployment cannot mitigate this without disabling crash capture entirely,
which costs the diagnostics operators need for exactly the crashes that leak.

Requested change

A non-environment path for the MCP bearer token, e.g.:

  • write it to a 0600 file and pass the path, or
  • pass it on an inherited fd — the same shape as the existing
    --bootstrap-fd flag ("Read one-time bootstrap secrets from the given file
    descriptor"), which shows the project already treats fd-passing as the right
    channel for secrets.

A constraint I cannot resolve from outside: the Codex MCP client is
configured here via bearer_token_env_var, which implies the client itself
expects an environment variable. If that is the only mechanism Codex supports,
this may need a client-side change first, or a T3-side mitigation instead
(shorter session TTL, or revoking the MCP session on provider exit so a
recovered token is dead on arrival).

Environment

t3code-bin 0.0.38-1 (Arch), runtime 0.0.42
Arch Linux, kernel 7.1.9, systemd 261
providers spawned under a single user service; multiple sessions share one UID

Not asking for

No mitigation is needed on my side beyond what an operator can already do. Filing
this because the leak is structural to the channel rather than to any
deployment's configuration, and because no operator-side setting can close it.

Activity

  1. juliusmarminge commented on Sep 16, 2026

    @juliusmarminge
    juliusmarminge
    on Sep 16, 2026
    Member

    Triage

    Confirmed on current main (0f5a1513e). This is a real Codex credential-channel bug, not a wash of #10020. The thread-scoped t3-code MCP bearer is injected into the Codex child environment as T3_MCP_BEARER_TOKEN. On Linux, systemd-coredump persists that entire block as COREDUMP_ENVIRON in the journal. The reporter’s scope is right: session-bounded, same-UID, no operator knob that keeps crash capture and drops this field.

    What the code does

    CodexAdapter.startSession reads the in-memory MCP session and puts the raw token in the child env, then tells Codex to read it from that variable (apps/server/src/provider/Layers/CodexAdapter.ts). The -c flags only name the URL and the env-var name; the secret itself is not on argv. That is why this is the inverse of the Claude argv leak, not a duplicate of it.

    The token is a 32-byte random bearer from McpSessionRegistry. The registry stores a SHA-256 hash only. /mcp is mounted outside the environment auth stack; this token is the only guard for the t3-code toolkits.

    Lifetime, as designed:

    Path Token fate
    ProviderService.stopSession clearMcpSession → revokeActiveMcpThread (eager)
    startSession / recover failure same revoke
    New session on the same thread issueActiveMcpCredential revokes the thread first, then mints a new token
    Unclean death with no later touch DEFAULT_LIVENESS_WINDOW_MS = 24 hours
    runtime.error / session.exited not revoked. Ingestion marks the thread error and clears turn state. No stopSession.
    Session reaper 30-minute idle, and it skips an active turn / background liveness

    That matches the reporter’s measurement: a token taken from a dump returned 401 after the session ended; a freshly minted one returned 200. The gap they could not see from outside: a crash that has not yet gone through stopSession leaves a still-valid token in COREDUMP_ENVIRON. On a host where several provider sessions share one UID, any of those sessions that can run journalctl --all can use it until revoke, replacement, or the 24h window.

    journalctl --output=json omits the field because it is large; --all shows it. coredump.conf on systemd 261 has no exclude for COREDUMP_ENVIRON.

    Codex client constraint

    bearer_token_env_var is an env-var name, not a file/fd. Codex’s current HTTP MCP config is:

    • bearer_token_env_var / env_http_headers — still environment
    • http_headers — static values. Passing the bearer here via -c would put it on argv. Do not do that.
    • http_headers_helper — local command that prints {"Authorization":"Bearer …"}. Documented for local HTTP MCP. Codex caches helper headers and refreshes once on 401/403. Explicit bearer / OAuth wins over a helper Authorization, so a helper path must drop bearer_token_env_var.

    That helper is the non-env channel that exists today without a Codex client change. --bootstrap-fd is the T3 server bootstrap path. It is not a Codex MCP auth mechanism; do not try to reuse it as one.

    Related, not duplicates

    Issue / PR Why it does not close this
    Open #10020 / open #10090 Claude: bearer serialized onto --mcp-config argv. #10020 triage even pointed at Codex’s T3_MCP_BEARER_TOKEN as the “stronger” pattern. #10090 moves Claude onto the env channel this issue is about. Same secret, opposite surface. Do not attribute Closes #12031 to #10090.
    #4659 Keeps credentials alive across turns that never touch MCP (touch). Lifetime, not the env channel.
    #4189 Revoke-by-providerSessionId for overlapping sessions. Not coredump.
    ACP / OpenCode / Claude on main Different auth surfaces; not this spawn env.

    No open or merged PR removes T3_MCP_BEARER_TOKEN from the Codex child environment, adds http_headers_helper, or revokes on provider process exit.

    Suggested fix

    Keep this as a bugfix on the Codex MCP spawn path, plus one lifecycle hardening that every provider benefits from.

    1. Get the bearer out of Codex environ. Prefer http_headers_helper over a new Codex feature. Write the token to a 0600 file under serverConfig.secretsDir (already 0700; not the workspace). Helper prints {"Authorization":"Bearer <token>"} and nothing else. Pass only -c mcp_servers.t3-code.http_headers_helper=… plus the URL. Omit T3_MCP_BEARER_TOKEN and bearer_token_env_var. Delete the file in clearMcpSession / session finalizer.
    2. Do not put the raw bearer in http_headers via -c. That is Keep the Claude t3-code MCP bearer out of process arguments #10020 for Codex.
    3. Revoke on provider death, not only on stopSession. runtime.error and session.exited should clearMcpSession (or revokeProviderSession for that provider session). A token recovered from the dump of the process that just died should be dead on arrival.
    4. Tests: with an MCP session, spawned Codex env has no raw bearer / no T3_MCP_BEARER_TOKEN; argv has no Authorization / Bearer; helper file is 0600 and is gone after stop; runtime.error / session.exited makes resolve(token) undefined.
    5. fix(claude): keep MCP credentials out of process arguments #10090: if Claude must leave argv, do not stop at a child env var on Linux coredump hosts. Same file/helper belongs there too. Do not treat fix(claude): keep MCP credentials out of process arguments #10090 as closing this.

    A shorter default TTL alone is not the fix. Crashes are common on a busy host; T3 already sees them.

    Workaround

    None in-app. Operator-only, and they cost the diagnostics the dumps are for:

    • Disable coredumps for the provider unit / LimitCORE=0
    • Tighten journal ACL so the provider UID cannot read COREDUMP_ENVIRON
    • Do not run mutually untrusted sessions under one Unix account

    journalctl without --all hiding the field is not a mitigation.

    Classification: bug · accepted · moderate (thread-scoped /mcp bearer; Linux systemd-coredump; same-UID multi-session; live until stop/replace/24h, and crash does not revoke today)
    Labels: add bug, accepted, via-triage, codex
    Discord tags: providers, linux

  2. juliusmarminge
    added
    bugSomething is broken or behaving incorrectly.
    acceptedfeature request accepted
    via-triageFiled through npx t3 triage
    codex
    on Sep 16, 2026

  3. only21mil commented on Oct 11, 2026

    @only21mil
    only21mil
    on Oct 11, 2026
    Contributor

    Status on current main (477282263a):

    • Codex no longer uses the env channel. The bearer goes in http_headers in the thread config sent over the app-server JSON-RPC connection (apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts:1321-1322).
    • Claude is fixed on main. fix(server): keep the Claude MCP token out of process arguments #17408 moved the token off argv into the child env as T3_CODE_MCP_AUTHORIZATION, which put Claude on this issue's channel. fix(server): send Claude MCP servers over the control channel #17898 now sends the MCP servers with setMcpServers over the SDK control channel instead (apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts:646 and :687).
    • ACP joined this channel with the V2 orchestrator (feat(orchestrator): introduce new orchestrator #2829), after the triage. It tells every agent, Grok and Antigravity included, to spawn the t3 acp-mcp-bridge stdio server with T3_ACP_MCP_AUTHORIZATION in its env (packages/provider-acp/src/server/adapter.ts:705). Registry ACP agents also get it in their own process env and in their client terminals, through processEnvironment (:714).
    • Pi still sets T3_MCP_BEARER_TOKEN in the pi child env (packages/provider-pi/src/server/mcpInjection.ts:313-314).

    A dummy variable set on a process that was then crashed with SIGSEGV landed in COREDUMP_ENVIRON.

    Scope notes:

    • Capture needs core_pattern piping to systemd-coredump and a signal that dumps core. SIGKILL and OOM kills do not. With a piped pattern the kernel aborts the dump only when RLIMIT_CORE is 1. With 0, systemd-coredump skips the core file but still writes the journal entry, COREDUMP_ENVIRON included. A dummy-variable test of both values showed this.
    • For registry ACP agents and Pi, every command the agent runs inherits the variable, so a crash of any of them dumps the token, not only a crash of the provider CLI. For Grok and Antigravity it reaches only the bridge process.
    • V2 now releases the session when the provider event stream fails (apps/server/src/orchestration-v2/ProviderSessionManager.ts:1978-1982, runtime_error), and the release revokes the credential unless another session still holds it (:1027). That shortens the window for provider crashes. A crashing subprocess does not end the session, so its token stays valid until stop, archive, delete, idle reap, rotation or the 24 h liveness window.
    • The same user can read the entry, since it lands in that user's journal. So can root, the journal-reading admin groups the distro grants, and anyone holding a copy of the journal.

    Until the fix ships, LimitCORE=1 on the unit that runs T3, or prlimit --core=1 in front of the command that starts it, stops the kernel handing crashes to systemd-coredump. Descendants inherit the limit, at the cost of every crash dump under it. A shell's ulimit -c 1 is no substitute, because bash counts it in 1024-byte blocks (512 in POSIX mode), so the limit never becomes 1. The triage's LimitCORE=0 still lets the journal entry through.

    The fix is in #17957. It moves ACP and Pi to an owner-only credential file per thread, so the token is no longer in their child environments or in those processes' COREDUMP_ENVIRON.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    acceptedfeature request acceptedbugSomething is broken or behaving incorrectly.codexvia-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions