Claude Code Tasks vs Beads vs a Shared Board: Tracking Agent Work

Claude Code’s task list, Beads and a shared board answer three different questions. Claude Code’s task list is Claude’s own checklist for the job in front of it, kept on your machine. Beads is an issue tracker built for coding agents, stored as a versioned database inside the repository and synced through git remotes, so agents keep a dependency-aware plan across sessions and machines. A hosted board such as fenbs is where people and assistants share one list, each with a role, and every change is recorded with who made it. Many teams will use two of the three at once. The comparison below is structural, taken from each project’s own documentation.

Claude Code’s task list

When Claude works through a multi-step job it keeps a checklist with the TaskCreate, TaskList, TaskGet and TaskUpdate tools: items that are pending, in progress or completed, optionally depending on each other. Ctrl+T shows it in the terminal. What the Claude Code documentation↗ (opens in a new tab) says about where it lives:

• Items survive context compaction, and a session resumed with --resume or --continue still has them.
• Setting CLAUDE_CODE_TASK_LIST_ID shares one list across sessions, in a named directory under ~/.claude/tasks/.
• In the experimental agent teams↗ (opens in a new tab) mode, teammates share a task list and claim work from it. The documentation says that list persists locally and is never uploaded.
• On some newer models these tools are off by default↗ (opens in a new tab) and have to be switched on.

It is built for one thing and does it well: keeping Claude oriented during the work. It has no idea of people, no roles and no record of who changed what, because nobody but Claude and you is expected to look at it. The differences from the older to-do tool are covered in Claude Code tasks vs to-dos.

Beads

Beads is an open-source project started by Steve Yegge and released under the MIT licence. Its README↗ (opens in a new tab) describes it as a “distributed graph issue tracker for AI agents, powered by Dolt” that “replaces messy markdown plans with a dependency-aware graph”. You install a command-line tool, bd, and run bd init in a project.

bd create "Fix auth bug" -p 1 -t bug
bd ready                   # tasks with no open blockers
bd update bd-a1b2 --claim  # sets assignee and in_progress
bd close bd-a1b2 "Fixed"

• Storage is a Dolt database — a version-controlled SQL database — in a .beads/ directory. The default embedded mode has a single writer; a server mode supports several concurrent writers.
• It syncs between machines with bd dolt push and bd dolt pull against your git remote. Hash-based ids such as bd-a1b2 are designed so that agents on different branches do not collide.
• Dependencies are first class: bd dep add links issues, and bd ready lists only work whose blockers are closed.
• It keeps memory for agents too: bd remember stores an insight, and bd prime prints workflow context and memories for an agent at the start of a session.
• bd setup claude installs hooks and settings for Claude Code; other assistants get an AGENTS.md section. There is also an MCP server, beads-mcp.
• It is a command-line tool with JSON output. The project lists community-built viewers, including terminal and web interfaces, rather than shipping its own.

Beads does mention roles, but in a different sense from access control. bd init --contributor routes planning issues to a separate place so they stay out of pull requests to a project you do not maintain, and maintainers are detected from their git credentials. The README describes no per-person permissions inside Beads; who can change the data follows who can write to the database and the remote.

A shared hosted board

The third approach takes the list out of the repository and the machine. fenbs is one example: a hosted board that people use in a browser or on the phone app, and that assistants such as Claude Code, Cursor or ChatGPT reach over MCP.

• Members are people and AI assistants, each holding a role on the board. A role can be narrow — see and comment only, or add tasks and edit only the ones it added.
• An assistant connects by browser sign-in and acts as the person who approved it, narrowed by the scopes ticked then: read, write, comment. Revoking it stops that assistant alone.
• Every change is kept in the board’s history with who made it, and an assistant’s changes read “Claude via” the person it acts for.
• Tasks have a kind (feature, enhancement or bug), a priority from 1 to 10, a project, and one of four lanes: To Do, Next Up, In Progress, Completed.
• AI context — notes on how you work — sits on the board, so any connected assistant reads the same notes.

What it does not do matters as much. fenbs has no dependency graph and nothing like bd ready: related tasks are linked both ways, but a link does not block anything. It is not in your repository, it does not follow branches, and it needs a connection to fenbs.ai.

Side by side

• Where it lives — Claude Code: files under ~/.claude/tasks/ on one machine. Beads: a Dolt database in the repository’s .beads/ directory, synced through the git remote. Board: a hosted service.
• Who can see it — Claude Code: you and Claude, on that machine. Beads: anyone with the repository and the Beads tool, or a community viewer. Board: the board’s members, in a browser, on a phone or through an assistant.
• Persistence — Claude Code: across compaction and resumed sessions, and across sessions with a shared list id. Beads: as long as the database and remote, with versioned history. Board: until someone deletes a task, and deleted tasks can be restored.
• Several agents — Claude Code: subagents report back, and agent teams share one local list. Beads: designed for it, with atomic claims, collision-free ids and server mode for concurrent writers. Board: any number of assistants and people on one board; moving a task to In Progress is the claim, by convention.
• Human review — Claude Code: you read the list in the terminal. Beads: bd show gives an issue’s detail and audit trail, from the command line or a viewer. Board: lanes, comments and a history people read without a terminal.
• Permissions — Claude Code: none; it is Claude’s own list. Beads: none described inside the tool; access follows the repository. Board: roles per member, scopes per assistant, and revoke.

Which to use, and when to combine them

The deciding question is who needs to read the list.

• Only Claude, for the job in front of it: the built-in task list. It costs nothing to set up and disappears from view when the job is done, which is right for steps.
• Agents working a long, branching plan inside one codebase, run by developers who live in the terminal: Beads fits. Its strengths — the dependency graph, bd ready, sync through git — are aimed squarely at that.
• Anyone who does not open the repository — a product owner, a client, a colleague on another team — or anyone who must be able to limit or revoke what an assistant may change: a shared board.

They also stack. Claude’s task list holds the steps of one piece of work under any of the others. A team could keep an agent’s detailed dependency graph in Beads and put the outcomes people care about on a board, with a comment linking the two. The one thing to avoid is copying every step into every layer: pick the level at which each list is read, and write to it at that level. For the board end of that, an issue tracker for AI agents covers filing and triage, and a task-tracking workflow for Claude Code the session rhythm.