Agents view directory picker loses recently-used directory after daemon self-restart on auto-update (v2.1.220)

Status Open

Reported on v2.1.220

Maintainer reply None cached

Activity 0 comments · opened Aug 1, 2026

Summary

After the daemon self-restarted twice for an auto-update (v2.1.220), a directory that was actively used via the agents view (FleetView) that same morning disappeared from the directory picker's recently-used list. Directories not used since the update remained listed; the one with the freshest usage vanished.

Environment

Claude Code v2.1.220 (daemon mode, origin=transient), Linux (Ubuntu, headless server)
Agents view used from desktop app / claude.ai, connected to the server's daemon
The affected directory is not a git repository (plain project folder); other listed directories are git repos, which initially sent us down the wrong path — repo status turned out to be irrelevant

Timeline (UTC, from `~/.claude/daemon.log`)

07:13:39 [supervisor] binary at .../claude.exe changed (mtime changed) — self-restarting for upgrade
07:13:40 [supervisor] ─── daemon start ─── version=2.1.220 ... origin=transient
07:37:43 [bg] bg settled <session> (killed)        <- last fleet session in the affected directory
07:43:41 [supervisor] binary changed (mtime changed) — self-restarting for upgrade
07:43:42 [supervisor] ─── daemon start ─── version=2.1.220

Immediately after this, the affected directory was gone from the @-directory-picker in the agents view. ~/.claude.json still contained the project entry with a current lastStartTime, and session transcripts under ~/.claude/projects/<dir> were intact. At least one older job directory under ~/.claude/jobs/ referenced by that project had been deleted.

What did NOT bring it back

Adding a CLAUDE.md to the directory
Initializing a git repository in it
Running a fresh headless claude -p session in the directory

What DID bring it back

Explicitly selecting the path once in the picker — after that the directory is listed again normally.

Expected

A directory that was in active use minutes before an automatic daemon upgrade should survive the restart in the recently-used list — or at least be recoverable without the user knowing the trick of re-selecting the full path.

Possibly related

#66358 (daemon orphans bg workers after auto-update / control-key skew) — same trigger (binary mtime change → self-restart), different symptom.

Feature suggestion

Make the picker list user-editable: pin/unpin directories, remove stale entries, and a visible free-text path input. That would also make losses like this a non-event.

View original on GitHub ↗