Passing --add-dir suppresses the initial positional prompt; the session opens and never starts a turn

Passing --add-dir stops a session from submitting its initial positional prompt. The session opens, the prompt sits in the composer, and no turn starts. Removing --add-dir and changing nothing else makes the same prompt submit immediately.

This breaks any wrapper that starts a session on a prompt and grants a directory in the same command: the session looks healthy and never does any work.

Environment

• Claude Code 2.1.259 and 2.1.263, both affected
• Installed as an npm global package
• Linux x86_64, Node 20.19.2

Steps

With a prompt file at <dir>/prompt.md holding one line, and the working directory somewhere other than <dir>:

| # | Command | Result |
|---|---|---|
| 1 | claude @<dir>/prompt.md | Submits, answers |
| 2 | claude "reply with the single word ready, then stop" | Submits, answers |
| 3 | claude --add-dir <dir> @<dir>/prompt.md | Opens, no turn starts |
| 4 | claude --add-dir <dir> "reply with the single word ready, then stop" | Opens, no turn starts |
| 5 | claude --bg @<dir>/prompt.md | Starts working |

1 and 3 differ only by --add-dir. 2 and 4 differ only by --add-dir. The prompt form does not matter: a text argument and an @<path> reference behave the same way in each pair.

Expected

3 and 4 submit their prompt and start a turn, as 1 and 2 do.

Actual

The session opens and waits indefinitely. Submitting the prompt by hand works normally, so the session itself is healthy.

Notes

• Not version-specific across the range tested: 2.1.259 and 2.1.263 behave identically, with background auto-updates disabled to hold the version steady.
• An @<path> reference outside the working directory is read without --add-dir, so the grant is not what makes the prompt reachable in case 1.
• The failure is silent. The process starts, the interface renders, and nothing distinguishes it from a slow first turn, so a calling process sees a healthy child that never works.