A queue of coding agents with a cockpit. Queue a job from a Linear issue or a line of prose, watch the pipeline reproduce, root-cause, fix, attack and verify it phase by phase, and come back to a pull request that carries its evidence — Report → Cause → Changes → QA. A job that can't prove its fix stops at a gate with a written notice instead of opening a PR.
Queue the work during the day. Start the batch when you step away. Come back to pull requests — and to an agent that remembers what it learned last night.
npx @nightqueue/nq init
Needs Claude Code with your own subscription, Node ≥ 22 and gh. Nothing leaves your machine.
The Studio — nq studio — on 127.0.0.1, over a demo home (npm run studio:demo): three projects, one night, one pull request per job.
Studio
the queue, every job phase by phase, an operator terminal, integrations — in your browser
CLI
nq in your terminal, same commands the Studio runs
MCP
queue and memory tools from Claude Code and Claude Desktop
Same queue, same pipeline, same memory underneath.
The Studio
One page for the whole night: what is queued, what is running, what each phase did and what it cost, and the operator that prepares the next job — without leaving the browser.
/jobs/J-213
A job, phase by phase
The pipeline card shows the nine slots of the run from second zero, each in its agent's colour: triager, explore, architect, coder, qa-guardian, verifier, runtime, commit. A slot the tier skips is hatched and says why.
Active time, tokens, cost and attempts, with the token share per phase
The live log as a tree — phase → lane → event — with answers, hand-backs and phase reports you can expand
The notice the job wrote: what was missing, what was done, how it was validated, what is still open
Operator
An operator beside the queue
A Claude Code session in a terminal docked at the bottom of every page, or split beside it. It runs nightqueue open in the home: investigate a bug, reproduce it in a throwaway worktree, review a finished job's pull request, prepare the next job. It never edits code, runs it, commits or opens a pull request — the queue does that.
Resume in terminal reopens the session that did the work of any job in gate, failed or done
Each Linear issue has Analyse: the operator opens with that issue as its first prompt
Up to six terminals; a restarted Studio reaps what a dead one left
+ Add job
Queue in prose, or from Linear
Pick the project, write the whole request as prose, let the pipeline decide the tier or force one, set a priority. The drawer shows the exact queue_add call it will make — the same one the CLI and the MCP server make — and Queue and start runner starts the batch at once. With Linear connected, the issues card below the queue lists the workspace by team and project, and Queue on an issue opens this drawer with the issue as the job's origin: the runner reads it at claim, the close comments the pull request on it and moves it to the team's completed state.
Settings
Integrations, orgs and projects
GitHub, Expo, Linear, Sentry and Discord as connections — a secret is never shown again once saved. Orgs and projects are registered, edited and removed from the same page, through the runtime's own commands under the config lock.
How a job runs
Every phase is a dedicated subagent with its own instructions, running in a git worktree it cannot leave. Each phase writes an artifact the next one is gated on; a job that needs a decision stops with a written notice, and one command — or one click in the Studio — sends it back. Bugs and risky changes get the full track; a docs or config change runs implement → verify → PR and your project's own checks.
## Report
The close of PR `#72` stopped at preflight with `checks-red`. CI had two failures unrelated to that diff, each in a different check, and both were clock-sensitive flakes (CI run 37814924665):
- `test-worktree`: "queue_cancel with stop … release_worktree needs stop" failed with "the refused stop wrote to the row", because `attempt_rows[0].elapsed_s` went from 0 to 1.
…
## Cause
- **B1:** `ATTEMPT_ROWS` derives `elapsed_s`/`end_epoch` from `datetime('now')` while an attempt is open. The test claims a job, which leaves an open attempt, and compares `getJob` before and after the refused cancel. The comparison breaks whenever a one-second boundary falls between the two reads.
…
## Changes
- `test/mcp/server.test.mjs`: a `rowAtRest` helper drops only `elapsed_s`/`end_epoch` from `attempt_rows` before the before/after comparisons. Every other field is still compared, and the product SQL is untouched.
…
## QA### Automated
- `npm test` (full suite) — PASSED ✅
- `node --test test/queue/close-steps.test.mjs` (85 tests, the close engine against the fake gh, covering re-run then merge, failed twice, non-Actions red, aborted re-run and `--force`) — PASSED ✅
…
Opened by nightqueue
What it does
Root cause, with proof
Your project's own checks run on every job. Higher risk tiers also reproduce the problem first, fix the cause, then face adversarial QA and a runtime check; the lowest tier runs implementation and verification only. The pull request carries the evidence, not a promise.
From Linear
Queue from a Linear issue link or --origin linear:MK-42. The runner reads the issue at claim. When the pull request merges, the close comments on the issue with the pull request, and moves it to the team's completed state only if it is not already completed or canceled and the team has a completed-type state.
A backlog, not a chat
nq queue add records a deliverable; nq queue run works through the whole backlog unattended and comes back with one pull request per job.
A memory that compounds
Lessons, project memories and structural indexes survive between runs — hybrid recall (BM25 + optional local embeddings), scoped per project and per org. The job page shows what was recalled and what was applied. Every run makes the next one cheaper.
Human gates, not silent failures
A job that needs a call stops with a written notice. Retry it with a note from the Studio, or nq queue retry <id> --note "…", and the job goes back to the queue.
Orgs and projects
One home, many repositories, grouped by org — each with its own lessons, memory and connections, managed in the Studio's settings and exposed to Claude Code and Claude Desktop through an MCP server.
Inspectable, resumable
Every phase hands off through a file. A run can be read, resumed and audited after the fact; Resume in terminal in the Studio, or nq queue session <id>, reopens the conversation that did the work.
Why not just a chat session
A chat session
nightqueue
Who drives
you, prompt by prompt
the pipeline, phase by phase
Root cause
fixes what you described
reproduces first and fixes the cause on bugs and risky changes; proves every job
Memory
gone when the window closes
lessons and memories persist per org
Visibility
a scrollback
the Studio: every job, phase by phase, with its cost and its notice
Quality gate
whatever you remember to ask
your project's own checks on every run; adversarial QA on bugs and risky changes
Output
a diff in a terminal
a reviewable pull request with a report
When it runs
while you watch
while you sleep
A first night
# oncenpx @nightqueue/nq init# runtime, commands, MCP server, Claude Code plugin
cd your-repo && nightqueue setup # register the project# the day
nq queue add "fix the flaky worker"
nq queue add "add the retry to the uploader"
nq queue run # start the batch, detached, when you step away# the morning
nq studio # what each job became, phase by phase, in the browser
nq queue retry 7 --note "rename the column" # answer a gate (or Retry with a note, in the Studio)
nq queue close 8 # merge its pull request through the closing pipeline
Everything above has a button in the Studio. Inside Claude Code, /nightqueue:queue turns the plan under discussion into a job and /nightqueue:resolve runs the pipeline on the spot. nightqueue open — or the Operator button — starts the operator: investigate, triage and prepare a job without knowing any of the above.
Status
Experimental, pre-1.0, used daily on real repositories by its author. The CLI, the MCP tools and the on-disk formats can still change between minor versions; every change a user would notice is in the changelog. Free and local. A hosted Team tier — one shared queue and memory per org, runners on your team's machines — is planned; the local product stays free and is never degraded to push it.
nightqueue
