Sidequest

Sidequest gives Claude Code a local ticket board. A task saved as a ticket keeps its instructions, reproduction steps, status and discussion outside the conversation, so Claude can pick it up after compaction or in a new session. From the same board, Claude can plan a story, dispatch the ready tickets to executor agents running in parallel, and review their verified results before integrating them.

Sidequest is a large plugin and the mod is one part of it: a hooks module of guards around tool calls. The board, the tickets and the dispatch loop come from the rest of the plugin.

What it does

• The board. /sidequest:board opens a local Kanban dashboard with To do, Doing and Done columns across your projects, plus search, filters, stories, comments, links between tickets and reminders. Ticket data stays under ~/.claude/sidequest, or SIDEQUEST_HOME if you set it.
• Plain requests. You ask Claude to save a task with its progress and next steps, show the backlog, explain what blocks a ticket, or dispatch, review and integrate. Claude works the board through the plugin’s MCP tools.
• Parallel work. Categories route each ticket to a model and effort. Ready tickets are split into waves that share no files, and each ticket runs as a background executor agent. A codebase ticket comes back as a verified revision and other work as a verified project snapshot; larger or riskier changes can get an independent review.

Dispatch uses the model access you configure, and any paid subscription or API usage follows that provider’s pricing and limits. Sidequest routes across Claude models on its own; non-Claude routes need the same author’s Model Gateway plugin.

Install

Needs Claude Code 2.1.287 or later and Node.js, which runs the plugin’s hook scripts.

claude plugin marketplace add Eigenwise/eigenwise-toolshed
claude plugin install sidequest@eigenwise-toolshed

The author installs it at project scope (--scope project). Reload plugins or start a new session, then open the board with /sidequest:board or ask Claude to show it. For a first try, the author suggests saving a small task as a checkpoint and reading it back in a new session. After an upgrade, reload again so the session picks up the current board connection and executors.

How it works

The mod: guards on tool calls

hooks/guards/register.ts hooks tool.call, prompt.submit and the classic UserPromptSubmit event, the last only to note the transcript path. It reads the command of every Bash and PowerShell call and the arguments of Agent, file edit, SendMessage and board calls, then lets each one through, adds a hint, or refuses it.

• Deletes. A recursive delete aimed at your home folder, ~/.claude, the folder above home or a drive root is refused.
• Git. Commands that can destroy or publish work, such as git reset --hard, git clean -f, a whole-tree checkout or restore, a forced checkout or a push, are checked, and so is git run in the shared checkout. This guard fails closed: a command it cannot check is refused.
• Executors. Every Agent spawn, and any edit or command the board’s rules could refuse, goes to the plugin’s force-exec-bypass.js script as a local process with a 10-second limit. It can refuse the call, or rewrite its model, isolation and mode to match the ticket’s route; a spawn it cannot check is refused. Executors are held to the tools the board’s deniedTools setting allows, messages to a closed executor or one whose worktree is gone are refused, and so is polling a dispatched agent with TaskOutput, since its result arrives on its own.
• Shell slips. On Windows, a Bash command whose backslash paths the shell would mangle is refused with the fix. Heredocs are refused inside isolated worktrees. Hints cover npm .cmd shims in Start-Process, container paths that Git Bash rewrites, and an executor running the same command three times.
• Board nudge. After 25 edits or non-read commands in the main loop without a board call, a toast suggests one owner and a focused check, once per session.

Every decision comes from the board’s dispatch-snapshot.json on disk. When one of the other checks fails, it steps aside and says so in the status line. The module makes no network or model calls.

The rest of the plugin

The board is an MCP server plus the local dashboard. Classic command hooks in hooks.json handle the lifecycle: session start and end, prompts, compaction, stop, subagent start and stop, worktree creation, and a quota fallback when an Agent call fails. They add short notes to Claude’s context, which the author caps at 2 KiB at session start, 1 KiB on a prompt and 1,500 bytes after compaction, so a Sidequest session carries a few extra input tokens. The prompt note fires once per session, on a prompt that looks like a work request, to say that dispatch is available.

Limitations

• Only what is recorded on a ticket survives compaction. The author’s advice is to keep decisions, progress, verification evidence and the next action in the ticket’s description or comments.
• For worktree storage and recovery the author points to the generated reference on the project’s docs site, and suggests asking Claude to inspect or clean up local worktrees rather than guessing at lifecycle commands.