--add-dir with a nonexistent path is silently accepted (no error/warning), unlike the file-vs-directory check

Description

--add-dir with a path that does not exist is silently accepted — no error, no warning, exit code 0 — even though a related invalid case (path exists but is a file, not a directory) IS caught with a clear message. There's no signal to the user that the requested directory grant did not happen.

Steps to reproduce

claude --add-dir /tmp/definitely_missing_dir_98765 -p "reply with just: DONE"

Expected behavior

Either an error/exit code, or at minimum a warning to stderr, indicating the path does not exist — consistent with how the file-vs-directory case is already handled.

Actual behavior

DONE

Exit code 0. No stderr output. Session proceeds as if --add-dir had never been passed.

For contrast, an existing invalid case IS caught:

touch /tmp/afile123.txt
claude --add-dir /tmp/afile123.txt -p "reply with just: DONE"

/tmp/afile123.txt is not a directory. Did you mean to add the parent directory /tmp?
DONE

Environment

• Claude Code version: 2.1.233
• OS: macOS (arm64, Apple Silicon)
• Reproduced twice with fresh nonexistent paths, consistent result each time.

Why this matters

A typo'd or stale path in --add-dir (e.g. from a script or CI config) silently loses the intended extra scope with zero indication — the only invalid-path case the CLI currently validates for is "exists but wrong type," not "does not exist at all," which is arguably the more common mistake.

_{AI disclosure: this report was investigated and reproduced by an AI coding agent (Claude, via Atlas) under human supervision.}