A plain human tt state or tt status in a repo can report room_not_found while agents are active in that repo's room.
Reproduced in ~/dev/ai/talking-stick while three agents and a chat console were joined to live room 3286fa22:
$ env -u CLAUDECODE -u CLAUDE_CODE_SESSION_ID tt whoami --json # human:wojtek (human_cli_default)
$ env -u CLAUDECODE -u CLAUDE_CODE_SESSION_ID tt state --json # {"error":"room_not_found"}
The same identity reads another repo's room fine, and an agent identity reads this room fine.
Cause (from ~/.local/share/talking-stick/cli-sessions.json): human:wojtek has two entries for this canonical path, pointing at room ids b94f3d80… (updated 2026-04-26) and 294ddc1a… (2026-06-08). Both rooms have since been deleted, which is normal: rooms are ephemeral. The agent that works has one entry pointing at the live room. So the read uses the cached room id and fails, rather than re-resolving the room by path when the cached one no longer exists.
Also observed:
- 11 (agent_id, canonical_path) pairs in that file have more than one entry, so the cache isn't keyed uniquely per agent and path, and it's unclear which entry wins.
- The file has 482 entries and 179 KB with no apparent pruning of entries for deleted rooms.
Not affected: tt chat mints a fresh human:<user>:chat:<id> identity per console, so the operator console doesn't hit this — only plain human CLI reads.
Suggested fix: when a cached room id resolves to room_not_found, drop that entry and fall back to path resolution; dedupe entries per (agent_id, canonical_path) on write; prune entries whose room no longer exists.
A plain human
tt stateortt statusin a repo can reportroom_not_foundwhile agents are active in that repo's room.Reproduced in
~/dev/ai/talking-stickwhile three agents and a chat console were joined to live room3286fa22:The same identity reads another repo's room fine, and an agent identity reads this room fine.
Cause (from
~/.local/share/talking-stick/cli-sessions.json):human:wojtekhas two entries for this canonical path, pointing at room idsb94f3d80…(updated 2026-04-26) and294ddc1a…(2026-06-08). Both rooms have since been deleted, which is normal: rooms are ephemeral. The agent that works has one entry pointing at the live room. So the read uses the cached room id and fails, rather than re-resolving the room by path when the cached one no longer exists.Also observed:
Not affected:
tt chatmints a freshhuman:<user>:chat:<id>identity per console, so the operator console doesn't hit this — only plain human CLI reads.Suggested fix: when a cached room id resolves to
room_not_found, drop that entry and fall back to path resolution; dedupe entries per (agent_id, canonical_path) on write; prune entries whose room no longer exists.