Desktop app ignores env.PATH from settings.json (sandbox overrides)

Related: #42248 — filed independently with additional findings that may be useful for debugging this.

Key additional data points from #42248:

1. launchctl setenv PATH is also ignored, even after full quit/restart with no lingering processes. However, OTHER environment variables set via launchctl setenv ARE visible to the Desktop app (confirmed via set in Bash tool). This suggests the Desktop app/sandbox is specifically overriding PATH while inheriting other session-level env vars.

1. Symlinks in /usr/local/bin/ don't help — the minimal PATH (/usr/bin:/bin:/usr/sbin:/sbin) excludes /usr/local/bin too, not just /opt/homebrew/bin.

1. Shell snapshots at ~/.claude/shell-snapshots/ contain the full correct PATH but it is not applied to the tool environment.

1. VS Code extension with the same settings.json env.PATH DOES work — confirming this is Desktop-app-specific, not a settings.json parsing issue.

1. Concrete impact: The Read tool cannot find pdftoppm (poppler) for PDF rendering, even though the binary exists and works when called via Bash with the full path.

The launchctl finding is particularly interesting — if other env vars come through but PATH doesn't, something in the Desktop app or its sandbox is explicitly constructing/replacing PATH rather than inheriting it from the session environment.

Closed #42639 as a duplicate of this. Adding context:

This is a regression. The v2.1.78 release notes explicitly state: "Fixed Bash tool not finding Homebrew and other PATH-dependent binaries when VS Code is launched from Dock/Spotlight." This fix regressed by v2.1.87.

The shell snapshot correctly captures functions and aliases from profile scripts (proving they ran) — but the final export PATH= line reflects the parent process's minimal PATH, not the login shell's resolved PATH.

Same issue here. macOS (Darwin 25.2.0, Apple Silicon), Claude Desktop app v1.569.0.

/Users/xxxx/.claude/settings.json has env.PATH set to include /Users/xxxx/.local/bin:/usr/local/bin, but the actual Bash session only gets /usr/bin:/bin:/usr/sbin:/sbin.

This breaks all MCP servers (e.g. uvx-based Jira/Confluence MCP) and official plugins like playwright@claude-plugins-official — they're enabled in settings but can't start because the binaries aren't found.

Was working fine last week. Confirmed regression.

(Until last week, the desktop app automatically inherited the full shell environment without any explicit env.PATH configuration in settings.json. Now it only picks up the minimal sandbox PATH.)

Related datapoint from testing this on macOS 2.1.111 today — the Desktop env problem extends to ANTHROPIC_BASE_URL, and the mechanism appears to be explicit override in the code-tab child process, not just sandbox filtering.

Setup

• ~/.claude/settings.local.json in an active project:

``json
{
"env": {
"ANTHROPIC_BASE_URL": "http://localhost:4000",
"ANTHROPIC_CUSTOM_HEADERS": "x-litellm-api-key: Bearer <redacted>"
}
}
``

• Local LiteLLM proxy listening on 127.0.0.1:4000.
• CLI (claude from terminal) correctly routes to LiteLLM. Desktop code tab does not — it connects directly to 160.79.104.10:443 (Anthropic).

What I tested

As a workaround I tried launchctl setenv ANTHROPIC_BASE_URL http://localhost:4000 then fully quit and relaunched Claude.app. Then inspected process environments with ps eww:

| Process | ANTHROPIC_BASE_URL in env |
|---|---|
| /Applications/Claude.app/Contents/MacOS/Claude (parent) | http://localhost:4000 ✅ inherited from launchd |
| claude.app/Contents/MacOS/claude (code-tab child) | https://api.anthropic.com ❌ overridden |

Other env vars (ANTHROPIC_AUTH_TOKEN, OPERON_SANDBOXED_NETWORK=1, empty ANTHROPIC_API_KEY) pass through or are injected. But ANTHROPIC_BASE_URL is force-set on the child process.

Implication

This rules out the common macOS workarounds:

• launchctl setenv — parent inherits, child overrides
• LSEnvironment plist — same override would fire
• Shell wrapper launching Claude.app — same

The only remaining technical path is a TLS-intercepting network proxy, which is not reasonable for regular use.

So in addition to env.PATH being ignored, env.ANTHROPIC_BASE_URL is actively overwritten — which blocks LLM gateway / LiteLLM routing for Desktop code tab users even if the sandbox issue is fixed. Worth addressing together, or splitting out if you'd prefer a separate issue.

Repro is trivial: set ANTHROPIC_BASE_URL via launchctl setenv, relaunch Desktop, ps eww -p <code-tab-pid> | tr ' ' '\n' | grep ANTHROPIC_BASE_URL.