sudocode CLI
A memory and coordination layer for coding agents: specs and issues live in git while agents work in parallel
- 295 ★ on the repository
- Last commit
- Apache-2.0
Broad access
Why this level
- Runs coding agents in parallel, and they edit files and create branches, worktrees and commits
- A local server manages agent execution
- Agents over MCP get read and write access to the project's issues and specs
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add cli/sudocodeDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- Runs coding agents in parallel, and they edit files and create branches, worktrees and commits
- A local server manages agent execution
- Agents over MCP get read and write access to the project's issues and specs
This is third-party code. Review the repository files before installing.
What it does
sudocode adds a memory and coordination layer for coding agents to a repository. Human requirements live in specs and answer what to build. Agent plans and context live in issues and describe how to implement it. Both sit in git, and people and agents alike read and edit them. An agent can leave breadcrumbs in an issue for the next one, so context in long work survives between sessions. The package contains a CLI, a local server with a UI and an MCP server. The CLI manages specs, issues and the links between them, while the server syncs memory and shows an issue kanban, a spec editor and an execution panel. From the UI you can start Claude Code, Codex, Cursor and other agents in parallel, give them feedback and watch their trajectories. When issues have dependencies, the graph can run as a workflow. Issues go in topological order, changes accumulate in a temporary branch or worktree, and every issue gets its own commit.
Who it is for. For developers who run large tasks with several coding agents and want intent and plans stored in the repository.
Good fit when
- The task is long and context must pass between agent sessions as files in git
- Requirements and plan need separating: specs for people, issues for agents
- You want to run several agents in parallel and watch them in one kanban
- A dependency graph of issues must run in order with a separate commit for each
- You already use Spec-Kit, OpenSpec or Beads and want sync with them
Not a fit when
- The edit is small and done in one session: specs and issues are overhead
- Agents may not change code or create branches and worktrees
- You need Jira or Linear integration today: it is still planned
- You do not want a .sudocode folder with JSONL data in the repository
Example request
Create an auth-system spec, break it into issues with dependencies and run them in graph orderLimitations
- The author advises running sudocode through npx so a global install does not cause Node version conflicts.
- Jira and Linear integrations are not ready yet.
- A planning command that calls the configured agent on its own is still only planned, so you have to ask the agent for a plan by hand.
- Auto-sync between Markdown and JSONL runs with a delay of about five seconds, and git and AI resolve merge conflicts.
How to disable. Delete the .sudocode folder from the repository and the package with `npm uninstall -g sudocode`. Remove the Claude Code plugin with `claude plugin uninstall sudocode`.
FAQ
How do I install sudocode?
Run `npm install -g sudocode`, then `sudocode init` in the project root and `sudocode server` for the UI. The author suggests npx over a global install if Node version conflicts appear.
How do I connect sudocode to Claude Code?
Run `claude plugin marketplace add sudocode-ai/sudocode` and `claude plugin install sudocode`. For other agents the repository has a quick start guide.
How is a spec different from an issue?
A spec holds human intent: requirements, decisions, research questions. An issue holds agent intent: what to do under a spec. They link through references like [[@ISSUE-001]].
Where is the data stored?
In the .sudocode folder: JSONL and Markdown files in git are the source of truth, while the SQLite cache in cache.db stays local and out of git.
Which systems does sync work with?
Beads, Spec-Kit and OpenSpec, in both directions. Enable integrations in Settings, Integrations or with `sudocode plugin`.
Discussion
No questions or reviews yet.
Related
CLI toolsA portable .agent folder with memory, skills and protocols that plugs into many coding agents and keeps its knowledge when you switch tools
A tmux-based TUI that runs Claude Code, Codex and other agents in one list: status, quick prompts, worktrees and diff review
One local memory for Codex, Claude Code, Cursor, Hermes Agent and OpenClaw: agents hand off tasks, review each other and refine their skills overnight
CLI Agent Orchestrator
CLI Agent Orchestrator (CAO)
A CLI that coordinates several coding agents: a supervisor delegates tasks to specialists in parallel or in sequence across isolated tmux sessions
An orchestrator for agents: the workflow is defined in code, every step is enforced, key points need human approval and decisions go into an immutable journal
Memory for coding agents in plain Markdown: the agent keeps specs, decisions and lessons itself, and each new session starts from them. No vector database
Comparison with similar tools
Entries that share the main search query, and how they differ.
| Entry | Official | Repository stars | Main difference |
|---|---|---|---|
| sudocode (this entry) | no | 295 | |
| OpenSpec | no | 73,368 | a proposal and spec process with no agent runs, while this adds issue memory and parallel execution |
| Agent Kanban | no | 493 | skills for a task board in a separate service, while here the board and memory live in your git |
| CLI Agent Orchestrator | no | 1,489 | a supervisor hands tasks to terminal agents, while here the graph of specs and issues lives in the repository |
README in short
The core idea is context as code: the repository becomes a distributed memory database where git distributes the data. A step-by-step example goes from spec to execution.