nightshift Orchestrates GitHub Issues With DAGs

nightshift is Shaurya Sethi’s Rust CLI for letting a coding agent work through GitHub issues while you are away. It deals with a familiar long-horizon coding problem: agents lose the plot when too much planning, code, review, and dependency state lives in one growing chat. The useful idea is simple and sharp: put the plan in GitHub’s issue graph, then let the agent take one ready node at a time.

nightshift is a small open-source project, not a platform. As of September 2026, the repository was mainly Rust, MIT licensed, and still early, with 11 GitHub stars and a last push on 2026-09-08. For people building Codex CLI workflows with OpenAI Codex, OpenAI’s coding agent, the project is interesting less as a finished product and more as a concrete pattern: use durable repo objects to control agent scope. Gemini Workshop is part of Harness Institute.

What nightshift actually runs

nightshift points at a PRD stored as a GitHub issue, finds its child issues, checks dependency relationships, and repeatedly hands ready work to the coding agent you choose. The README describes the loop as branch, implement, open PR, merge, repeat, stopping when every child issue is done.

A DAG is a directed acyclic graph: a set of ordered tasks where dependencies point forward and no task loops back to itself. In nightshift’s case, the DAG is not a markdown checklist hidden inside an issue body. It is GitHub’s native issue relationship model.

That distinction matters. If issue 42 is blocked by issue 37, nightshift reads that relationship through GitHub, not by asking a model to infer it from prose. The trap to avoid is assuming a beautiful PRD body is enough. The project warns that membership and ordering come from parent, blockedBy, and the ready-for-agent label.

A tiny example looks like this:

# Create child work under a PRD issue
gh issue create --parent 120 --title "Add retry handling to webhook delivery"

# Express ordering with GitHub relationships
gh issue create --parent 120 --blocked-by 121 --title "Expose webhook retry status in admin UI"

# Mark only safe, prepared work as agent-ready
gh issue edit 121 --add-label ready-for-agent

The exact command flags depend on your installed GitHub CLI version and repository setup. nightshift lists gh 2.94.0 or newer as a prerequisite, along with Rust, Cargo, Git, and a signed-in coding agent.

Why developers cared about context rot

The Hacker News hook was not “Rust CLI automates GitHub.” Developers have seen plenty of those. The hook was the author’s complaint that long-horizon agent features can suffer from context rot: the longer a single agent conversation runs, the more stale decisions, partial assumptions, and irrelevant details pile up.

nightshift’s answer is to make GitHub the memory boundary. Each issue becomes a fresh unit of work. Dependencies stay outside the model. The agent receives a smaller task, works it, and the system advances only when the graph says the next task is ready.

That is an opinionated architecture. It says the planner should not be a giant chat transcript. It says the source of truth should be boring, queryable, and visible to humans.

The trap is thinking this removes review. It does not. It moves the failure mode. Instead of “the agent forgot what mattered,” you now have “the graph was wrong,” “the wrong issue was labeled ready,” or “the merge criteria were too loose.” Those are better failures in many repos because humans can inspect them without replaying a conversation.

The clever bit is the work selector

The project’s most useful design choice is that the work selector is agent-agnostic. nightshift does not need to be the smartest code writer in the room. It needs to decide what should be attempted next and pass that bounded task to the agent you specify with --agent.

That fits how many engineers already use Codex CLI. You keep OpenAI Codex focused on one repo-local change, then require a verification loop before the work is considered done. If you are exploring Codex CLI workflows, nightshift is a good reminder that orchestration can be outside the model.

A repo rule for this style can be short:

# AGENTS.md

## Agent work boundaries
- Work only on the GitHub issue named in the current task.
- Do not start blocked or unlabeled issues.
- Before opening a PR, run: cargo test && cargo fmt --check && cargo clippy -- -D warnings.
- Include the issue number, commands run, and any skipped checks in the PR body.

This is not magic. It is a hook boundary. The agent can be flexible inside the task, but the repo decides what “done” means.

The trap is making AGENTS.md a dumping ground for every preference anyone has ever had. Keep durable rules there: test commands, architectural constraints, PR expectations, and security boundaries. Put task-specific detail in the issue.

Where Codex fits in the story

For Codex users, nightshift is a story about control surfaces. Codex CLI can do useful repo work, but long-running work benefits from external structure: scoped instructions, reliable commands, and artifacts a reviewer can read after the agent exits.

A practical Codex verification loop might be:

# local verification the agent should run before handoff
cargo fmt --check
cargo clippy -- -D warnings
cargo test

git diff --stat
git diff -- README.md src tests

That loop gives the agent a finish line and gives the reviewer a receipt. It also keeps the conversation from becoming the only place where truth exists.

This is the same reason projects that run multiple agents often add tracking outside the chat. We covered a related shape in Ditch Tracks Multiple Codex Agents: once more than one agent is touching code, you need a visible queue, not vibes.

The trap is giving a coding agent permission to both choose scope and decide whether the result is acceptable. nightshift narrows the first part with GitHub relationships. Your repo still has to narrow the second part with tests, review, and merge rules.

When to try it, and when to skip it

Try nightshift when your backlog already has clean issue boundaries. It is a better fit for “implement these five related child issues in dependency order” than for “understand this messy product area and figure out what we should do.”

It is also a better fit when each issue can be verified independently. A migration with strong tests, a UI polish pass with screenshots, or a set of API endpoint fixes can work. A cross-cutting redesign with unclear acceptance criteria will probably produce expensive noise.

Use it carefully in repos with production secrets, broad deployment permissions, or weak test coverage. The README pitch is “go to sleep with a backlog and wake up with merged PRs,” which is charming, but unattended merge rights are a serious boundary. Start with draft PRs or manual merges unless the repo has earned more autonomy.

This is where MCP belongs in the conversation too. MCP is useful when an agent needs external systems such as GitHub, documents, databases, or issue trackers, but every server should have a clear permission boundary. For a first experiment, keep GitHub write access narrow and avoid giving the agent deployment or production-data access.

Try nightshift safely

Use this as a small experiment, not a grand process change. One PRD, three child issues, one agent, manual merge.

A safe starter checklist:

• Pick one PRD issue with three child issues.
• Add ready-for-agent only to the first unblocked issue.
• Add a repo-local AGENTS.md rule with test commands and PR requirements.
• Run nightshift against a non-critical repo or branch policy that requires review.
• Require the PR body to list commands run, files changed, and any skipped checks.
• Remove the label from any issue whose acceptance criteria are ambiguous.

The best first result is not “merged while sleeping.” It is “the agent opened one boring PR that a human could review quickly.” That is how you learn whether the graph, prompts, and verification loop are doing useful work.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Common questions

How should teams start with Codex?

Start by writing down one visible team rule for Codex, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

Which Codex artifact should teams standardize first?

Standardize the smallest artifact that reviewers already touch: an AGENTS.md instruction, MCP note, or verification checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

How do teams know the convention is working?

The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Codex teams deciding which AGENTS.md instruction, CLI workflow, MCP boundary, or verification loop to standardize next around “nightshift Orchestrates GitHub Issues With DAGs.”
• Best first artifact: turn the named fix into an AGENTS.md rule, verification checklist, MCP note, or review receipt before the next automated run.
• Best comparison angle: compare the workflow against the current Codex CLI review loop, shell boundary, and evidence trail; keep the path that leaves the shortest auditable trail.

Further reading

• nightshift — source
• OpenAI Developers — Codex CLI
• GitHub — openai/codex
• OpenAI developers: Codex CLI docs

Next move

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.