I run four tmux sessions with 20-30 Claude Code chats each, across 30-plus Go services, a mobile app, infra repos and a data pipeline. The agents cope fine. I didn’t. Long efforts branch into many PRs and sub-issues, ops work pulls me sideways, and after a few weeks nobody holds the whole picture, including me. When I pulled “losing track” apart, it was three separate problems: What’s blocked on what, and what’s ready now? This lived only in my head. Which session did what, and why? I found a PR stuck for weeks where the reasoning only ever existed in a chat that was long gone. What do we know? Facts and gotchas. Claude Code’s auto-memory already covered this one. Things I ruled out: GitHub only: issues are read by colleagues and product. Session URLs, “blocked until I decide X” and “sitting in dev waiting for a soak” are scratch state, and a comment per agent session turns an issue into noise. A knowledge base (gbrain, Karpathy-style LLM wiki): good for question 3, but a wiki page has no notion of ready versus blocked. A custom dashboard: brittle, and either every chat has to remember to update it, or it only reads GitHub and can’t show what I deliberately keep off GitHub. What fit was Beads ( bd ), Steve Yegge’s issue tracker for coding agents: dependencies, bd ready / bd blocked , external refs to GitHub issues and PRs, free-form notes. How it’s wired: One shared database: I start sessions from an umbrella directory that isn’t a git repo, so I set BEADS_DIR in the Claude Code settings. Every session, subagent and worktree hits the same local database. Efforts and tasks: long-running efforts are top-level beads. Tasks hang under them with a repo:<name> label and an external ref to the GitHub issue or PR. Every agent run is bookended. At the start it finds the bead, checks bd blocked and claims it with bd update --claim . At the end it writes what happened into the notes and closes it or marks it blocked. There’s no persistent “agent in charge” in Claude Code; the database is what survives. GitHub gets one comment per issue, with a hidden marker, edited in place. Gotchas I hit: bd init injects a block into CLAUDE.md telling agents to use Beads instead of other memory, and writes an AGENTS.md . I removed both. bd show --json hides closed dependencies, so blocker checks use bd blocked . Children inherit parent labels by default, and making an effort depend on its last child creates a cycle. Claims are keyed to the user, not the session, so two parallel sessions can claim the same bead. On top I use mardi-gras ( mg ) as a read-only TUI: I browse, pick a bead, and hand its ID to a Claude session. Gas Town is on my radar for unattended runs, but not yet. It’s been running for about a week, with ten efforts and ~130 beads. Longer write-up with the reasoning here: https://tskulbru.dev/posts/beads-local-shadow-for-agent-work I’m not affiliated with Beads, mardi-gras or Gas Town in any way. I’m just a user, and the only link to something of mine is the blog post. How are others handling in-flight state across many agent sessions? submitted by /u/serrghi
Originally posted by u/serrghi on r/ClaudeCode