Shinobi

by numbererikson

328 downloads

Not rated

GitHub

About

Shinobi gives every AI coding agent on your machine — and every cloud Claude session — one shared task spine, decision log, and searched dead-ends ledger. Every failed approach is logged and semantically checked before an agent proposes a similar one, so agents stop repeating mis

Details

Author: numbererikson
Downloads: 328
Categories: AI, Project Management

- Task spine: projects and subtasks that persist across sessions
- Decisions that survive: record architectural choices with rationale
- Semantic dead-end search: matches similar failed approaches before new code
- Mobile approvals: request_approval pushes decisions to your phone
- One brain, every device: laptop, cloud session, and mobile share the same store
- Plugin system: drop-in custom tools via .js files or npm packages

Setting up with Highlight

This MCP is not yet compatible with Highlight’s one-click setup. However, you can still use it with Highlight by following these steps:

Download and install Highlight from highlightai.com/download
Navigate to the plugins tab and select "Add Custom Plugin"
Configure the plugin with the settings below

Plugin Name Shinobi

Command (node, npx, python, etc.)

Please refer to the README for specific instructions on how to obtain API keys or other required environment variables.
Enable "Start Automatically" if you want the plugin to start when Highlight launches

Setting up with Cursor

Open Cursor's settings
Navigate to the MCP section
Click "Add new Global MCP server"
Copy and paste the configuration below based on your operating system

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

Setting up with Claude Desktop

Open Claude Desktop's settings
Go to the Integrations tab
Click "Add MCP Server"
Use the configuration below based on your operating system

Note: Make sure Claude Desktop is running before attempting to connect.

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

Setting up with Windsurf

Open Windsurf's preferences
Go to the Integrations section
Click "Add MCP Integration"
Use the configuration below based on your operating system

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

Setting up with Cline

Open Cline's settings
Navigate to the Integrations section
Click "Add MCP Server"
Copy and paste the configuration below based on your operating system

Note: Make sure to restart Cline after adding the configuration.

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

Setting up with Goose

Open Goose's preferences
Go to the Integrations tab
Select "MCP Servers"
Click "Add New Server"
Use the configuration below based on your operating system

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

From the repository

Install the npm package globally, run shinobi init in your project root to bootstrap the local database and config, then start the web dashboard with shinobi dashboard. The init command automatically writes .mcp.json for Claude Code and Cursor; other clients require manual configuration using the same command/args values. For multi-device setups, deploy shinobi serve as an HTTP MCP endpoint with bearer token auth.

`list_projects`

List Shinobi projects with progress. Filter by status, workspace, or include archived. Pass brief=true for a token-light listing (truncated descriptions, no summary blobs) and use get_project for full detail.

`get_project`

Get a single project by id, including its summary fields.

`create_project`

Create a new project. Tag with workspace (e.g. shinobi / shinobiapps / sitesnap) so cross-codebase work stays organised.

`update_project`

Patch a project. Only fields present in the patch are modified.

`archive_project`

Mark a project as archived (sets archived_at timestamp).

`unarchive_project`

Restore an archived project (clears archived_at).

`delete_project`

Permanently delete a project (cascades to subtasks, decisions, plans, etc.).

`list_tasks`

List subtasks. Filter by project_id, status, or claude session id.

`get_task`

Get a single subtask by id.

`create_task`

Create a subtask. project_id is optional (null = unrouted inbox task). Title+description are embedded for semantic recall when SHINOBI_EMBED_PROVIDER is configured.

`bulk_create_tasks`

Create multiple subtasks in a single transaction. Useful when seeding a project plan.

`update_subtask`

Patch a subtask. Rejects circular dependencies. Use status="todo" to reset an in-progress task.

`delete_subtask`

Permanently delete a subtask.

`claim_task`

Mark a subtask as in_progress and link the current session. Call BEFORE starting work so resume knows where you left off.

`complete_task`

Mark a subtask as done. Optionally pass a summary that will be attached to the linked session. Set notify:true to fire a "task done" mobile push (best-effort, never fails the completion) — meant for headless / dispatch-loop agents; leave false for interactive completes so you do not buzz your own phone.

`next_task`

Pick the highest-priority todo subtask whose dependencies are met. Optionally scoped to a project. Also returns matched dead-end warnings (semantic when SHINOBI_EMBED_PROVIDER is configured).

`log_decision`

Record a decision in the durable decision log. Architectural choices, library picks, tradeoffs, workarounds. Embeds summary+rationale for semantic recall when SHINOBI_EMBED_PROVIDER is configured.

`decisions_for_file`

Return every decision whose files_touched contains the given path. Useful when opening a file you have not touched in months.

`update_decision_status`

Move a decision through its lifecycle (open / fix_now / fix_later / wontfix / fixed / false_positive). Stamps decided_at automatically on closing states.

`log_dead_end`

Log an approach that demonstrably failed so future sessions do not re-try. Embeds approach+failure_reason for semantic match when SHINOBI_EMBED_PROVIDER is configured.

`check_dead_ends`

Preventive search BEFORE implementing an approach. Pass a description and optional file paths. Uses semantic similarity when SHINOBI_EMBED_PROVIDER is configured; otherwise FTS5 + filename overlap. Returns matching past failures.

`add_note`

Add a free-form note. Used for things that do not fit decision/dead_end/task. Body is fulltext-searched by recall(), and embedded for semantic recall when SHINOBI_EMBED_PROVIDER is configured.

`list_notes`

List notes ordered newest-first, optionally scoped to a project.

`save_plan`

Persist an approved plan as a new versioned snapshot. Auto-increments version per project.

`get_plan`

Return the latest plan for a project, or a specific version. Optionally include version history.

`get_context`

Get a project living context: conventions, dont_touch, test_patterns, deploy_notes, file_annotations. Returns null when no context row exists yet.

`update_context`

Patch a project's context. Only fields present in the patch are modified — others preserve their prior value.

`recall`

Search across decisions, dead ends, notes, and subtask titles/descriptions for a query string. Uses semantic similarity when SHINOBI_EMBED_PROVIDER is configured; otherwise FTS5-backed fulltext. Use this when you have lost the thread on an old project.

`history`

Return activity timeline (claim/complete/log_decision/log_dead_end/save_plan/...) ordered newest-first. Optionally scoped to a project, entity, or session.

`link_commit`

Link a git commit to a subtask (when commit message contains [SHI-N] tag) or attribute to projects via target_path match. Records to the activity timeline so 'history' shows commits next to claims/completions.

`extract_decisions`

Extract decision drafts from a conversation transcript via LLM (Groq Llama 3.3 by default, free tier). Drafts land in the decision_drafts table with status=pending — the user reviews them in the dashboard and approves to create real decisions via log_decision. Use at session boundaries when you want auto-capture of decisions you may have forgotten to log explicitly. Requires SHINOBI_LLM_PROVIDER + GROQ_API_KEY (or OPENAI_API_KEY).

`compress_session_summary`

Compress a project's recent activity + decisions + dead ends into a terse 3-paragraph markdown summary via LLM (Groq Llama 3.3 by default, free tier). When persist=true (default), stores on projects.recent_summary_md so next agent_bootstrap surfaces it as signal instead of raw 270-row noise. Requires SHINOBI_LLM_PROVIDER + GROQ_API_KEY (or OPENAI_API_KEY).

`agent_bootstrap`

Start an agent work session for a project. Returns project context, latest plan, selected/next task, open decisions, relevant dead ends, recent activity, and file-specific decisions. Optionally claims the task.

`session_closeout`

Finish an agent work session in one call. Records summary, changed files, completed tasks, decisions, dead ends, optional plan snapshot, and follow-up tasks.

`file_context`

Return guardrail context for files an agent is about to inspect or edit: project context annotations, decisions for each file, relevant dead ends, and recent activity.

`plugin_hello`

List discovered plugins and their registered tools. Use this to verify the plugin system loaded correctly. Plugins are loaded from ~/.shinobi/plugins/*.{js,mjs} (user tier) and node_modules/@shinobi/plugin-* (npm tier).

`request_approval`

Block waiting for the user to approve a decision via mobile push notification. Creates an approval row, fires web push to all subscribed devices with action buttons, and polls until the user responds (or timeout). Use when the agent hits a decision point that requires human judgment ("ship to prod?", "drop this feature?", "pick library X or Y?").

`notify`

Fire-and-forget mobile push to every subscribed device. Unlike request_approval, this does NOT block waiting for a response — use it from a headless / dispatch-loop agent to signal "done while you slept" (kind:"task_completed") or "I am stuck, come look" (kind:"blocked"). Returns a delivery summary; push failures never throw.

`ingest_findings`

Turn a list of audit / linter / code-review findings into a subtask graph the swarm can drain. Severity maps to priority (critical→urgent, high→high, medium→medium, low/info→low). Findings on the same file are chained (depends_on) so they run sequentially — agents never edit one file in parallel — while different files stay independent and fan out. Closes the loop: an AI review generates findings, the swarm fixes them, the dashboard reports done.

Claude Desktop / Cursor

Paste into your MCP client config file to install this server.

{
    "mcpServers": {
        "shinobi": {
            "shinobi": {
                "command": "npx",
                "args": [
                    "-y",
                    "@shinobiapps/shinobi",
                    "mcp"
                ]
            }
        }
    }
}

McpServers

{
    "shinobi": {
        "command": "npx",
        "args": [
            "-y",
            "@shinobiapps/shinobi",
            "mcp"
        ]
    }
}

Shinobi

The task spine for AI coding agents. Shinobi holds the decisions that survive across sessions, actively searches your past dead ends — semantically — before the agent writes code, and routes approvals to your phone. One brain, every device: laptop, cloud session, and mobile all wired to the same store.

Works with Claude Code, Cursor, Cline, Continue.dev, Zed — any MCP-compatible client.

> Status: v0.3 — autonomous agents. Run it as a hosted HTTP /mcp brain (the default deploy) or self-host a local instance. Mobile push, a headless dispatch loop, parallel swarm over git worktrees, and audit→subtask ingestion on top of the remote MCP foundation. 39 MCP tools, web dashboard, mobile approvals, plugin system, optional semantic recall.

What it does

Most tools try to be a memory bolt-on. Shinobi is the task spine your agent
works along — the durable backbone of work, decisions, and known-bad paths
that outlives any single session and follows you across every device.

- Task spine — projects + subtasks the agent claims, completes, or pivots; the persistent skeleton of multi-session work
- Decisions that survive — record architectural choices with rationale so the next session (on any device) doesn't re-litigate them
- Dead ends, searched before you build — every failed approach is logged and semantically matched the moment an agent plans a similar one, so it never burns a second session on the same wall. No other tool does this.
- Approvals on your phone — request_approval pushes the decision to your pocket; the agent blocks until you tap yes/no, wherever you are
- One brain, every device — laptop editor, Claude Code cloud session, and mobile chat all hit the same store over remote MCP; no sync step, no per-device drift
- Plans — versioned plan snapshots, retrievable mid-task
- Context — per-project conventions, "don't touch" rules, test patterns, deploy notes, file annotations
- Recall — fulltext (FTS5) by default, semantic (embedding-backed) when an embedding provider is configured
- Notes — free-form annotations and voice notes (audio_path field)
- Activity timeline — every write path lands in the timeline so you can replay what happened
- Git linking — link_commit ties commits to subtasks via [SHI-N] tags or via target_path attribution
- Web dashboard — Hono-served Kanban + decisions + dead ends + notes + plans + context + timeline + analytics
- Plugin system — drop a .js file in ~/.shinobi/plugins/ or install a @shinobi/plugin- npm package and register custom plugin_ tools

Hosted or self-hosted, your call. The default deploy is one remote brain
behind an HTTP /mcp endpoint (we run ours at shinobi.shinobi-apps.com); the
same binary still runs as a fully local single-machine instance when you'd
rather keep everything on your own box. BYO embedding provider only if you want
semantic recall.

> 🚀 New here? Follow Getting started — zero to a
> working brain in ten minutes. Going multi-device? Remote mode
> + $0/month cloud deploy.

Install

Requirements:

- Node.js 18+ on PATH
- C++ build toolchain for better-sqlite3 native build (most systems have prebuilt binaries; Windows may need Visual Studio Build Tools as fallback)

From npm (recommended)

npm install -g @shinobiapps/shinobi

The binary is shinobi (e.g. shinobi serve, shinobi dashboard).

From GitHub (latest, unreleased)

npm install -g github:numbererikson/shinobi

Pulls from main. Useful for trying unreleased fixes. On Windows you may need
to add your Node directory to system PATH before this works, because the
prepare build script runs in a subshell that does not always inherit
per-session PATH (Laragon, portable installs). If install fails with 'node' is not recognized, prefer the npm install above.

From a cloned source folder (for development / contributing)

git clone https://github.com/numbererikson/shinobi.git
cd shinobi
npm install            # triggers prepare → builds dist/
npm install -g .

Then bootstrap

In any project root where you want Shinobi available to your MCP client:

shinobi init
shinobi dashboard

init will:
1. Create ~/.shinobi/ with config.json, .env template, and shinobi.db (migrations applied)
2. Drop a .mcp.json snippet for the current project
3. Print next steps

shinobi init writes config for the two clients with a workspace-local
MCP convention out of the box:

- Claude Code — <workspace>/.mcp.json
- Cursor — <workspace>/.cursor/mcp.json

Restart the client and the mcp__shinobi__* tools become available.

For other MCP clients (Cline, Continue.dev, Zed), see the
MCP client setup section below.

Then open:

http://127.0.0.1:8765

On Windows PowerShell, if script execution blocks shinobi, use the .cmd shim:

shinobi.cmd dashboard

If you upgraded Node or copied an old node_modules, rebuild native dependencies:

npm rebuild better-sqlite3

Important: the code lives in the Shinobi folder, but the local memory database lives in:

~/.shinobi/shinobi.db

To move the tool only, copy/clone the Shinobi folder and run the install commands above. To move the existing projects, tasks, decisions, notes, and context too, either copy ~/.shinobi/ or use shinobi sync.

MCP client setup

Every snippet below uses the same JSON shape — command is the path
to the Node binary that's running Shinobi, args is [<absolute path to dist/cli.js>, "mcp"]. Print the exact values for your machine:

shinobi init --print-config

(Or read .mcp.json from any project where you already ran
shinobi init — the values are identical.)

Claude Code

Drops in automatically — shinobi init writes <workspace>/.mcp.json.
Restart Claude Code to pick up the server.

Cursor

Drops in automatically — shinobi init writes <workspace>/.cursor/mcp.json.
Works on Cursor 0.43+. Restart Cursor or reload the workspace.

For a global Cursor config (every project sees Shinobi), paste the
same snippet into ~/.cursor/mcp.json (or use Cursor Settings → MCP).

Cline (VS Code extension)

Open Cline's settings file:

- Windows: %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json
- macOS: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
- Linux: ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

Merge the contents of your project's .mcp.json into the file's
mcpServers object. Restart VS Code.

Continue.dev

Edit ~/.continue/config.json. Add Shinobi to the mcpServers array
(note: Continue uses an array, not an object like the others):

{
  "mcpServers": [
    {
      "name": "shinobi",
      "command": "/absolute/path/to/node",
      "args": ["/absolute/path/to/dist/cli.js", "mcp"]
    }
  ]
}

Use the values from your project's .mcp.json for command and args.

Zed

Edit ~/.config/zed/settings.json. Zed nests MCP servers under
context_servers:

{
  "context_servers": {
    "shinobi": {
      "command": {
        "path": "/absolute/path/to/node",
        "args": ["/absolute/path/to/dist/cli.js", "mcp"]
      }
    }
  }
}

Restart Zed.

Generic / other clients

Any MCP client that supports the standard { command, args } server spec
should work. Use the same values your .mcp.json has:

- command: absolute path to the Node binary running Shinobi
- args: [<absolute path to dist/cli.js>, "mcp"]

Avoid the bare shinobi command in MCP config — many clients spawn
servers with shell: false, which skips the OS PATH resolution that
makes shinobi work in a terminal.

Remote mode (the default deploy)

Host one Shinobi brain on a server and connect every device to it — your
desktop editor, Claude Code web/mobile sessions, any remote-MCP-capable
client. shinobi serve exposes the MCP endpoint at /mcp (streamable HTTP,
stateless, bearer-token auth) alongside the dashboard:

claude mcp add --transport http shinobi https://your-host/mcp \
  --header "Authorization: Bearer YOUR_TOKEN"

This is the recommended way to run Shinobi — one brain, reachable from every
device. The same binary still runs as a local single-machine instance if you'd
rather self-host everything on your own box. Full deployment guide (Docker,
Cloudflare Tunnel, GCP Always Free, client config):
docs/remote-mcp.md.

CLI

shinobi <command> [options]
Commands:

  init                            Bootstrap ~/.shinobi/ and drop .mcp.json in the current directory

  mcp                             Run the MCP server over stdio (invoked by the MCP client)

  migrate                         Apply pending SQL migrations

  dashboard                       Start the web dashboard on localhost (default port 8765)

  serve [--host H] [--port P]     Dashboard + MCP HTTP endpoint (/mcp) in one process — see docs/remote-mcp.md

  sync init <path> [branch]       Configure a local git repo as the cross-machine sync target

  sync push                       Snapshot the DB and commit it to the sync repo

  sync pull                       Restore the DB from the sync repo's snapshot

  sync status                     Show last push/pull timestamps and git status

  dispatch [--once|--drain]       Autonomous loop: pull next_task → run worker → complete/unblock → repeat

           [--project N] [--interval S] [--max-failures N]   Worker via SHINOBI_WORKER_CMD (e.g. 'claude -p "$SHINOBI_TASK_PROMPT"'); unset → dry-run

  swarm --agents N                N dispatch loops in parallel, each in its own git worktree/branch, one shared

        [--project N] [--drain]   brain. Atomic claim → no two agents take the same task. --no-worktree / --keep-worktrees

MCP tools (39)

| Group | Tools |
|---|---|
| Projects | list_projects, get_project, create_project, update_project, archive_project, unarchive_project, delete_project |
| Subtasks | list_tasks, get_task, create_task, bulk_create_tasks, update_subtask, delete_subtask, claim_task, complete_task, next_task |
| Decisions | log_decision, decisions_for_file, update_decision_status |
| Dead ends | log_dead_end, check_dead_ends |
| Notes | add_note, list_notes |
| Plans | save_plan, get_plan |
| Context | get_context, update_context |
| Recall | recall (FTS5 or semantic) |
| Timeline | history, link_commit |
| Workflow | agent_bootstrap, session_closeout, file_context |
| Extraction | extract_decisions, compress_session_summary |
| Approvals | request_approval |
| Notifications | notify |
| Findings | ingest_findings |
| Plugins | plugin_hello |

Architecture

| Layer | Tech |
|---|---|
| Language | TypeScript (strict mode, ES2022, NodeNext) |
| Runtime | Node 18+ |
| MCP | @modelcontextprotocol/sdk 1.x |
| Storage | SQLite via better-sqlite3 (WAL mode) |
| Dashboard | Hono + @hono/node-server (same process, localhost:8765) |
| Embeddings (optional) | OpenAI text-embedding-3-small / Voyage voyage-3-lite / Ollama nomic-embed-text |
| Migrations | Forward-only, sha256 checksum, schema_migrations table |

See docs/architecture.md for the request lifecycle and module layout.

Dashboard auth

The dashboard is open on loopback binds (127.0.0.1, localhost, ::1) and token-protected on any non-loopback bind. The token is read from SHINOBI_DASHBOARD_TOKEN, otherwise loaded from ~/.shinobi/dashboard-token, otherwise auto-generated and persisted there. /health is always open for probes.

Browser flow — open the dashboard with the token once and the cookie sticks:

http://192.168.1.10:8765/?token=YOUR_TOKEN

Curl / scripts — any of these works:

curl -H "Authorization: Bearer $SHINOBI_DASHBOARD_TOKEN" http://192.168.1.10:8765/api/projects/1/snapshot
curl -H "X-Shinobi-Token: $SHINOBI_DASHBOARD_TOKEN"      http://192.168.1.10:8765/api/projects/1/snapshot
curl --cookie "shinobi_token=$SHINOBI_DASHBOARD_TOKEN"   http://192.168.1.10:8765/api/projects/1/snapshot

See docs/configuration.md for the full env-var reference.

Cross-machine sync

Shinobi syncs your local SQLite database via a private git repo. Setup once per machine:

```bash

No reviews yet — be the first

Use Google, GitHub, or an email account so ratings stay tied to real people.

Email sign in

No reviews posted yet.

About

Details

Jump to

Setting up with Highlight

From the repository

list_projects

get_project

create_project

update_project

archive_project

unarchive_project

delete_project

list_tasks

get_task

create_task

bulk_create_tasks

update_subtask

delete_subtask

claim_task

complete_task

next_task

log_decision

decisions_for_file

update_decision_status

log_dead_end

check_dead_ends

add_note

list_notes

save_plan

get_plan

get_context

update_context

recall

history

link_commit

extract_decisions

compress_session_summary

agent_bootstrap

session_closeout

file_context

plugin_hello

request_approval

notify

ingest_findings

Claude Desktop / Cursor

McpServers

Shinobi

What it does

Install

From npm (recommended)

From GitHub (latest, unreleased)

From a cloned source folder (for development / contributing)

Then bootstrap

MCP client setup

Claude Code

Cursor

Cline (VS Code extension)

Continue.dev

Zed

Generic / other clients

Remote mode (the default deploy)

CLI

MCP tools (39)

Architecture

Dashboard auth

Cross-machine sync

Install

More like this

GitLab

Context 7

1Panel

🔎 GPT Researcher

Serena

FastMCP v2 🚀

`list_projects`

`get_project`

`create_project`

`update_project`

`archive_project`

`unarchive_project`

`delete_project`

`list_tasks`

`get_task`

`create_task`

`bulk_create_tasks`

`update_subtask`

`delete_subtask`

`claim_task`

`complete_task`

`next_task`

`log_decision`

`decisions_for_file`

`update_decision_status`

`log_dead_end`

`check_dead_ends`

`add_note`

`list_notes`

`save_plan`

`get_plan`

`get_context`

`update_context`

`recall`

`history`

`link_commit`

`extract_decisions`

`compress_session_summary`

`agent_bootstrap`

`session_closeout`

`file_context`

`plugin_hello`

`request_approval`

`notify`

`ingest_findings`