[Bug] Five ENOENT stack traces on every startup from missing remote-settings.json cache
Summary
When the Claude Code CLI starts and the user has no managed/remote settings (server returns 404), five [ERROR] stack traces are written to the debug log on every startup, complaining that ~/.claude/remote-settings.json doesn't exist. The CLI then proceeds normally — these errors are cosmetic — but they pollute every debug log and obscure real errors during triage.
The errors are self-inflicted: the CLI itself deletes the cache file when the server returns 404 (Remote settings: Deleted cached file (404 response)), then logs ENOENT stack traces the next time it tries to read the file it just deleted.
Repro
- Run
claudewith debug enabled on a machine with no remote/managed settings configured (i.e. the settings endpoint returns 404). - Inspect
~/.claude/debug/<latest>.txt.
Expected
- Missing cache file is normal; should be handled silently (e.g.,
existsSynccheck, ortry/catchswallowingENOENT). - Debug logs should contain real errors, not predictable cache-misses.
Actual
Five identical stack traces at [ERROR] level on every startup:
2026-04-26T13:43:07.053Z [ERROR] Error: Error: ENOENT: no such file or directory, open '/Users/c22/.claude/remote-settings.json'
at openSync (unknown)
at <anonymous> (/$bunfs/root/claude:12:947)
at iC (/$bunfs/root/claude:11:49098)
at readSync (/$bunfs/root/claude:12:875)
at aC (/$bunfs/root/claude:6105:113)
at sG (/$bunfs/root/claude:6107:226)
at gRA (/$bunfs/root/claude:178:8143)
at UBR (/$bunfs/root/claude:178:8306)
at TKD (/$bunfs/root/claude:179:1202)
at EAT (/$bunfs/root/claude:179:2080)
Five different call sites hit the same synchronous aC reader during startup (UBR → TKD → EAT, DLA → DLA → J_B, UBR → U_ → nFT, UBR → U_ → iFT, UBR → U_ → hOA). All five log a full stack at [ERROR].
A few hundred ms later the network fetch resolves cleanly at [DEBUG] level:
2026-04-26T13:43:07.476Z [DEBUG] Remote settings: No settings found (404)
2026-04-26T22:52:26.928Z [DEBUG] Remote settings: Deleted cached file (404 response)
So the CLI's own cleanup path (delete on 404) guarantees the file will be missing on the next startup, which guarantees the next batch of ENOENTs. Workarounds like echo '{}' > ~/.claude/remote-settings.json are wiped on the very next run.
Environment
claude --version:2.1.34 (Claude Code)- macOS (Darwin 25.2.0)
- Personal account, no managed/enterprise settings (settings endpoint returns 404)
- Pattern present in every debug log dating back at least to early April 2026
Suggested fix
Either:
- Wrap the synchronous read in
existsSync, or - Catch
ENOENTin theaCreader and log at[DEBUG](or not at all) for known-deletable cache files, or - Stop deleting the file on 404 and just leave an empty
{}so the read always succeeds.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗