claude-code - 💡(How to fix) Fix [BUG] settings.local.json env block not applied when ~/.claude/settings.json is a symlink (2.1.139 regression)

Official PRs (…)
ON THIS PAGE

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

The symptom is silent: no warning, no log entry, no error. The env block simply does not take effect.

Error Messages/Logs

Root Cause

Discovered because OTEL env vars in the settings.local.json env block stopped reaching the OTLP exporter after the auto-update to 2.1.139. The bug is not OTEL-specific — any env var in the block is affected. OTEL is just where it was visible because OTLP exports stopped landing at the configured collector.

Fix Action

Workaround

Place the settings.local.json at the symlink-target's directory (alongside the real settings.json) instead of next to the symlink:

ln -s ~/.claude/settings.local.json ~/Projects/dotfiles/settings.local.json

A symlink at that path is enough — the secret can stay in ~/.claude/. With this overlay file visible to the loader, 2.1.139 applies the env block as expected. Running sessions appear to hot-reload and pick up the change without restart.

This strongly suggests the loader, when settings.json is a symlink, looks for the settings.local.json overlay next to the resolved target rather than next to the symlink.

Code Example

mkdir -p ~/Projects/dotfiles
   mv ~/.claude/settings.json ~/Projects/dotfiles/settings.json
   ln -s ~/Projects/dotfiles/settings.json ~/.claude/settings.json

---

cat > ~/.claude/settings.local.json <<'INNER'
   { "env": { "REPRO_VAR": "from-settings-local" } }
   INNER

---

ln -s ~/.claude/settings.local.json ~/Projects/dotfiles/settings.local.json
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

When ~/.claude/settings.json is a symbolic link to a file outside ~/.claude/, 2.1.139 does not load the env block from ~/.claude/settings.local.json. Env vars defined there are silently absent at runtime — the SDK initializes without them.

2.1.138 loaded the same file correctly in the same layout. The behavior change is fully attributable to the binary; nothing else on the host changed.

The symptom is silent: no warning, no log entry, no error. The env block simply does not take effect.

What Should Happen?

The documented env block in ~/.claude/settings.local.json should be applied regardless of whether ~/.claude/settings.json is a regular file or a symlink.

Per the docs (https://code.claude.com/docs/en/settings):

Local scope ... env ... Environment variables that will be applied to every session

Steps to Reproduce

  1. Make ~/.claude/settings.json a symlink to a file outside ~/.claude/:

    mkdir -p ~/Projects/dotfiles
    mv ~/.claude/settings.json ~/Projects/dotfiles/settings.json
    ln -s ~/Projects/dotfiles/settings.json ~/.claude/settings.json
  2. Place a settings.local.json at the canonical user-scope location with an env block:

    cat > ~/.claude/settings.local.json <<'INNER'
    { "env": { "REPRO_VAR": "from-settings-local" } }
    INNER
  3. Launch Claude Code 2.1.139 and have it print the env var. It will be empty or undefined.

  4. Downgrade to 2.1.138 (same ~/.claude/settings.local.json file, same symlinked ~/.claude/settings.json) → REPRO_VAR is present.

Workaround

Place the settings.local.json at the symlink-target's directory (alongside the real settings.json) instead of next to the symlink:

ln -s ~/.claude/settings.local.json ~/Projects/dotfiles/settings.local.json

A symlink at that path is enough — the secret can stay in ~/.claude/. With this overlay file visible to the loader, 2.1.139 applies the env block as expected. Running sessions appear to hot-reload and pick up the change without restart.

This strongly suggests the loader, when settings.json is a symlink, looks for the settings.local.json overlay next to the resolved target rather than next to the symlink.

Probable Cause

The 2.1.139 changelog includes:

Fixed settings hot-reload not detecting edits to symlinked ~/.claude/settings.json

This is the only entry in 2.1.139 that touches symlink resolution for settings files. The fix likely changed the loader to resolve the symlink first, and the overlay-file lookup followed the same path resolution — breaking the case where settings.json is symlinked but settings.local.json is a regular file at the canonical location.

Error Messages/Logs

None. Failure is silent.

Claude Model

N/A — this is a settings-loading bug, independent of model.

Is this a regression?

Yes.

Last Working Version

2.1.138

Claude Code Version

2.1.139

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

zsh / tmux

Additional Information

Discovered because OTEL env vars in the settings.local.json env block stopped reaching the OTLP exporter after the auto-update to 2.1.139. The bug is not OTEL-specific — any env var in the block is affected. OTEL is just where it was visible because OTLP exports stopped landing at the configured collector.

Related but not duplicate:

  • #50567 / #52353 — also "OTEL metrics not exported on ≥ 2.1.113" but the hypothesized root cause there (OTLP exporter packages not bundled) does not match this case: in this layout, env vars passed via the shell on 2.1.139 produce successful OTLP exports. So OTLP exporters are bundled — they just don't get configured because the env block isn't loaded.
  • #56153 — docs note that subprocesses no longer inherit OTEL_* env vars (related env-propagation pattern, different mechanism).

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING