Bug
`agent-deck add -w -b -t <title> ...` followed by `session start <title>`
creates a session whose tmux pane never actually launches the `claude` process - it's left
sitting at a broken shell showing only:
```
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
```
Sending any input (including plain text) to the pane produces no response (the shell echoes
it back or silently no-ops, confirming `claude` never actually execed).
Reproduced 3 times tonight, ruling out the obvious causes each time
- First occurrence: worktree existed and was fully populated (verified via `ls -la` on the
exact path from a separate shell, all files present, correct timestamps).
- Restarted the session (`session restart`) - same error recurred.
- Removed and re-`add`ed pointing directly at the existing (already-created, verified-good)
worktree path instead of using `-w` - same error.
- Removed everything and created a completely fresh worktree with a new branch name via
`-w` again - same error, identical text.
Ruled out as the cause:
- Not a stale/deleted directory - verified accessible via a separate shell each time.
- Not tied to one specific worktree path - reproduced across 3 different paths/branches.
- Not a general host-level shell-spawning problem - `zsh -i -c "pwd"` and `bash -c "pwd"`
both worked fine directly on the host throughout.
- System was under heavy load earlier in the session but had recovered to normal levels
(load average ~25, down from a ~37 peak) by the time this was reproduced the 2nd and 3rd
times, so it isn't simply "too slow to init under load" either.
Impact
Any dispatch attempt via `add -w` during this window silently produced a session that
LOOKED created/started (agent-deck itself reported success, `health_class: alive`) but never
actually ran the intended agent - the only way to detect it was direct `tmux capture-pane`
inspection, not any agent-deck-level status field. Had to abandon dispatch entirely and
perform the actual work manually via direct SSH for the underlying task, which is not a
sustainable workaround for routine dispatch.
Environment
- agent-deck v1.9.75 (macOS 26 controller)
- Mac had experienced a severe resource-pressure episode earlier in the same session (swap
thrashing, ~10k IOPS disk activity) - possibly relevant residual state (e.g. a stale env var
or cached path inherited by agent-deck's own dispatch process), even though basic shell
functionality had otherwise recovered.
Expected
`add -w` should either succeed in spawning a working `claude` session, or fail loudly at
the `add`/`session start` CLI level with a clear error - not silently report success while
leaving a dead shell in the tmux pane.
Bug
`agent-deck add -w -b -t <title> ...` followed by `session start <title>`
creates a session whose tmux pane never actually launches the `claude` process - it's left
sitting at a broken shell showing only:
```
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
```
Sending any input (including plain text) to the pane produces no response (the shell echoes
it back or silently no-ops, confirming `claude` never actually execed).
Reproduced 3 times tonight, ruling out the obvious causes each time
exact path from a separate shell, all files present, correct timestamps).
worktree path instead of using `-w` - same error.
`-w` again - same error, identical text.
Ruled out as the cause:
both worked fine directly on the host throughout.
(load average ~25, down from a ~37 peak) by the time this was reproduced the 2nd and 3rd
times, so it isn't simply "too slow to init under load" either.
Impact
Any dispatch attempt via `add -w` during this window silently produced a session that
LOOKED created/started (agent-deck itself reported success, `health_class: alive`) but never
actually ran the intended agent - the only way to detect it was direct `tmux capture-pane`
inspection, not any agent-deck-level status field. Had to abandon dispatch entirely and
perform the actual work manually via direct SSH for the underlying task, which is not a
sustainable workaround for routine dispatch.
Environment
thrashing, ~10k IOPS disk activity) - possibly relevant residual state (e.g. a stale env var
or cached path inherited by agent-deck's own dispatch process), even though basic shell
functionality had otherwise recovered.
Expected
`add -w` should either succeed in spawning a working `claude` session, or fail loudly at
the `add`/`session start` CLI level with a clear error - not silently report success while
leaving a dead shell in the tmux pane.