Night Shift for GitHub issue backlogs

Context

Some issue backlogs contain work that is small, explicit, and reviewable, but still consumes attention if it must always be done during an active work block.

An overnight agent can absorb part of that execution if the loop is narrow:

• wake the machine
• pull the next eligible issue
• work in a fresh branch
• validate
• open a draft PR
• stop cleanly

The system should not try to automate approval. It should move bounded implementation work into an asynchronous review queue.

Decision / Insight

For a personal setup, a GitHub-specific loop is better than a generic multi-tracker abstraction.

The useful constraint is not portability. It is operational clarity.

Night Shift works best when the orchestration layer stays thin:

• GitHub Issues are the task source of truth
• the scheduler only decides when to run
• the runner only prepares the repo, invokes the agent, validates, and reports status
• review happens through draft PRs, not direct deployment or auto-merge

Breakdown

Options considered

1. Generic ticket-provider layer

   • More reusable on paper.
   • Adds abstraction before there is a real need for it.

2. GitHub-native runner

   • Matches the actual task system.
   • Keeps both implementation and debugging smaller.

Trade-offs

• A tracker-specific runner is less portable, but easier to trust.
• One branch per issue creates more PRs, but makes review cleaner and failure isolation better.
• Resetting to develop on every loop discards local dirt, but removes ambiguity from unattended runs.
• Draft PRs add one more GitHub write, but turn overnight work into a clean morning review surface.

Constraints

Before starting:

• run from a dedicated local automation folder, not from the managed repo
• wake the machine before the schedule window
• always reset the repo to develop
• always create a fresh branch per issue
• only process issues with the codex label

During each iteration:

• skip issues that already have an open PR on the expected branch
• use the issue body as the task source of truth
• let the agent modify code, but keep commit and PR creation in the outer runner
• run repository validations before push

Exit conditions:

• no eligible issues remain
• a repo preflight fails
• an issue fails and the runner logs the failure before continuing
• the nightly pass reaches the end of the configured repo list

Implementation

The implemented baseline is simple:

1. launchd schedules a midnight run on a Mac mini.
2. pmset wakes the machine before the run.
3. The runner resets the target repo to origin/develop.
4. GitHub Issues labeled codex are loaded in order.
5. Each issue gets a branch like night-shift/issue-6.
6. codex exec runs with the issue body embedded as the source of truth.
7. Lint and build run as explicit validation steps.
8. On success, the runner commits, pushes, opens a draft PR, and swaps codex to codex-review.
9. Slack receives run, repo, issue, and summary notifications.

The important architectural boundary is that the issue body drives the task, while the runner owns the control system around it.

Reusable Takeaway

Overnight agent workflows become safer when they stop trying to be general-purpose orchestration platforms.

For personal GitHub issue backlogs, a better baseline is:

• one issue per branch
• GitHub Issues as the source of truth
• draft PRs as the review boundary
• explicit wake, reset, validation, and stop rules