3 people reported
All time, since Oct 3, including 1 thumbs-up on GitHub.
Deleted daemon directory blocks TUI
“Deleting the shared daemon's startup directory still breaks new TUI sessions in 0.162.1, even when the new client's working directory exists.”
Is this your bug? What gets counted gets fixed. Pile on.
Paste this into your agent. It files your report, with your error and version.
I hit this bug: rapsheet.dev/sheets/codex/issues/14154/file Follow it to file my report. Show me the text before you send.
No install. No account. Public and anonymous. The link asks your agent for one report, nothing else. What it sends
New TUI sessions fail after daemon startup directory is deleted. Removing the directory that launched the shared daemon, such as a cleaned-up worktree, blocks startup in surviving directories.
Is this your bug?
File my report- Where
- TUI bootstrap
- Error text
Error: account/read failed during TUI bootstrap: account/read failed: failed to load workspace requirements (code -32603)- Versions
- 0.160.0 to 0.162.1
- Platforms
- Linux, macOS
- How bad
- Breaks a normal workflow.
Not quite your bug?
- Background server feature mismatch26 people
- Daemon access denied on Windows7 people
- Daemon executable not found loop3 people
Original reports2, newest first
- [0.162.1][macOS] Deleting daemon startup directory still breaks account/read and TUI bootstrapOn GitHub#54408
- Auto-started daemon with a deleted startup directory blocks every new TUI session with "Cannot use the background server" (experimentalFeature/list → "failed to reload config: No such file or directory")On GitHub#50619