[Bug]: Codex MCP env_vars are unavailable in desktop-launched provider profiles

[tarurar]

Before submitting

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

Area

apps/desktop

Steps to reproduce

1. Define credentials needed by a stdio MCP server in the login-shell environment. In this case, the variables are JIRA_URL, JIRA_PERSONAL_TOKEN, CONFLUENCE_URL, and CONFLUENCE_PERSONAL_TOKEN. Do not put their values in the Codex configuration.

2. Configure a separate Codex provider instance in T3 Code with a custom CODEX_HOME path.

3. In that Codex home's config.toml, configure the server by forwarding those variables:

   [mcp_servers.mcp-atlassian]
   command = "uvx"
   args = [
     "--from",
     "mcp-atlassian==0.23.0",
     "mcp-atlassian",
     "--toolsets",
     "jira_issues,jira_fields,jira_comments,jira_transitions,jira_projects,confluence_pages,confluence_comments",
   ]
   env_vars = [
     "JIRA_URL",
     "JIRA_PERSONAL_TOKEN",
     "CONFLUENCE_URL",
     "CONFLUENCE_PERSONAL_TOKEN",
   ]
   enabled_tools = ["jira_get_issue", "jira_search", "confluence_get_page"]

4. Start Codex from a terminal whose login environment contains the four variables. The MCP server exposes its tools.

5. Fully quit Codex, launch the T3 Code desktop application normally, select the custom Codex provider instance, and start a session.

6. Inspect the session's MCP tool catalog or ask it to use one of the configured read tools.

Expected behavior

The Codex session launched by T3 Code should be able to resolve the local environment-variable names explicitly requested by mcp_servers.<name>.env_vars, or T3 Code should provide a secure provider-profile setting for supplying them. The MCP tools should be exposed just as they are in a terminal-launched Codex session using the same CODEX_HOME.

Actual behavior

T3 Code loads the custom Codex home and recognizes mcp-atlassian as configured and enabled, but the server receives none of its required variables and publishes no tools. A capability check inside the session produces this agent summary (it is not a built-in T3 diagnostic string):

`mcp-atlassian` is configured and enabled, but its read endpoints are not exposed to this tool session.

Changing enabled_tools does not help because the underlying server advertises zero tools when its environment is missing.

Impact

Major degradation or frequent failure

Version or commit

T3 Code v0.0.38 (t3code-bin 0.0.38-1)

Environment

Arch Linux desktop application; Codex CLI 0.152.1; custom Codex provider instance using a separate CODEX_HOME; mcp-atlassian 0.23.0 over stdio.

Logs or stack traces

# Presence checks only; no values were printed.
login shell:                         required MCP variables 4/4
T3 desktop/backend processes:       required MCP variables 0/4
Codex app-server launched by T3:    required MCP variables 0/4

# Clean Codex app-server mcpServerStatus/list differential:
required variables absent:          mcp-atlassian tools=0
required variables present:         mcp-atlassian tools=19

# Direct tools/list against the configured MCP command:
required variables absent:          0 tools
required variables present:         45 tools before Codex enabled_tools filtering

The released desktop shell probe imports only a fixed set of names and does not include variables requested by Codex MCP configuration:

https://github.com/pingdotgg/t3code/blob/v0.0.38/apps/desktop/src/shell/DesktopShellEnvironment.ts#L70-L88

Codex documents env_vars as names that are read from Codex's local environment and forwarded to a stdio MCP server:

https://learn.chatgpt.com/docs/extend/mcp#stdio-servers

Screenshots, recordings, or supporting files

None. All credential values were deliberately excluded.

Workaround

Fully quitting T3 Code and launching it from a terminal after the work environment has been loaded causes the variables to be inherited and the tools to appear. This is brittle for desktop/autostart use and does not provide isolation between multiple Codex provider instances.

Related issues

• macOS: Electron app cannot access AZURE_API_KEY from ~/.zshrc when using env_key in Codex CLI config #317 reports the same Electron/login-shell inheritance boundary for a custom model-provider API key, but it was closed after a provider-specific credential workaround that does not cover MCP env_vars.
• [Feature]: Per-project environment variables #1703 requests broader per-project environment-variable support.
• The app does not load a local MCP server defined in .codex/config.toml. #297 concerns a local Codex MCP server failing for a different reason (relative working-directory handling).

Suggested scope

Avoid importing every login-shell variable indiscriminately. Possible bounded solutions are:

• resolve only the variable names explicitly requested by mcp_servers.*.env_vars in the selected Codex home's configuration; or
• add secure, provider-instance-scoped environment-variable references/values and merge them into the Codex app-server process environment.

[t3dotgg]

Note

🤖 GPT-6 Astra (preview) responding on behalf of Theo

This was closed as part of an automated cleanup pass. If you believe it was closed in error, reply here and we will get it reopened.

Closing this as an answered configuration request. The provider environment settings already provide the scoped values requested here. Add JIRA_URL, JIRA_PERSONAL_TOKEN, CONFLUENCE_URL, and CONFLUENCE_PERSONAL_TOKEN to the selected Codex provider instance, and mark both tokens Sensitive. These values enter that provider process. Automatic lookup of arbitrary shell variables is not implemented.