[BUG] Using `claude --settings` in v2.0.72 causes filewatcher crashes

Status Fixed / completed
Maintainer reply None cached
Activity 11 comments · opened Dec 18, 2025 · closed Jan 24, 2026

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?

Since auto-upgrading to v2.0.72, we see that any usage of the --settings flag on the command line causes claude to crash with various file-watcher errors. This can even be reproduced when passing an empty settings config claude --settings {}

EOPNOTSUPP: unknown error, watch '/var/folders/zp/x5d4hdb96k56ftqr_9tgwy0m0000gp/T/vscode-ssh-askpass-a0e4cd5294d48e1856862c274a470b147ec3'
     path: "/var/folders/zp/x5d4hdb96k56ftqr_9tgwy0m0000gp/T/vscode-ssh-askpass-a0e4cd5294d48e1856862c274a470b147ec3",
  syscall: "watch",
    errno: -102,
 filename: "/var/folders/zp/x5d4hdb96k56ftqr_9tgwy0m0000gp/T/vscode-ssh-askpass-a0e4cd5294d48e1856862c274a470b147ec3",
     code: "EOPNOTSUPP"

      at new FSWatcher (node:fs:29:31)
      at watch (node:fs:296:10)
      at l8_ (/$bunfs/root/claude:352:6174)
      at EyD (/$bunfs/root/claude:352:11388)
      at _watchWithNodeFs (/$bunfs/root/claude:352:6655)
      at _handleFile (/$bunfs/root/claude:352:7398)
      at _addToNodeFs (/$bunfs/root/claude:352:10425)
24 |     else if (typeof options === "string")
25 |       options = { encoding: options };
26 |     if (typeof listener !== "function")
27 |       listener = () => {};
28 |     this.#listener = listener;
29 |       this.#watcher = fs.watch(path, options || {}, this.#onEvent.bind(this));

Bun v1.3.4 (macOS arm64)

When running claude --debug --verbose --settings '{}', I see on the first line

2025-12-18T08:59:00.264Z [DEBUG] Watching for changes in setting files /Users/<username>/.claude, /Users/<username>/code/<project>/.claude, /var/folders/zp/x5d4hdb96k56ftqr_9tgwy0m0000gp/T, /Library/Application Support/ClaudeCode...

Seems like the attempt to watch the whole tempdir /var/folders/zp/x5d4hdb96k56ftqr_9tgwy0m0000gp/T is problematic.

What Should Happen?

Claude Code should start up without issue

Error Messages/Logs

Steps to Reproduce

  1. Upgrade to Claude Code v2.0.72
  2. Run claude --settings {}

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.0.71

Claude Code Version

2.0.72 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

_No response_

View original on GitHub ↗

11 Comments

AviPeltz · 8 months ago

i have the same issue, seems like Claude Code's file watcher is attempting to watch Unix socket files (.sock) in my temp directory
(/var/folders/.../T/). I get errors from other applications that have sockets running:

  • VS Code's git extension (vscode-git-*.sock)
  • SSH authentication helpers (ssh-askpass-*.sock)

Unix sockets can't be watched with fs.watch(), which causes the EOPNOTSUPP (operation not supported) error.

Elijas · 8 months ago

Same issue :(

Yidada · 8 months ago

Same issue 😭

OlaHulleberg · 8 months ago

A temporary fix I have found is to write whatever you are passing through --settings to a file instead (somewhere outside of that temp directory), and then pass the file instead.
This seems to cause the FSWatcher to watch the directory of that file, rather than the temp directory.

AviPeltz · 8 months ago
A temporary fix I have found is to write whatever you are passing through --settings to a file instead (somewhere outside of that temp directory), and then pass the file instead. This seems to cause the FSWatcher to watch the directory of that file, rather than the temp directory.

nice yeah that worked for me

FicoHu · 8 months ago

Same issue 😭

syw2014 · 8 months ago

Same issue 😭

VinCinx · 8 months ago

same

vlnd0 · 8 months ago

same

syw2014 · 7 months ago

Update to Claude Code v2.1.2, bugs gone!

github-actions[bot] · 7 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.