[BUG] settings.local.json env block not applied when ~/.claude/settings.json is a symlink (2.1.139 regression)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] 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/:

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

1. Place a settings.local.json at the canonical user-scope location with an env block:

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

1. Launch Claude Code 2.1.139 and have it print the env var. It will be empty or undefined.

1. 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).