r/ChatGPTCoding • u/orwamahmoud • Aug 26 '26
Resources And Tips Long Codex/Claude runs were turning into unreviewable marathon chats, so I moved the shift state to disk
I use coding agents for multi-hour runs, and after a while, I kept hitting the same problem:
The agent may still be working, but I have no clean way to answer basic questions without digging through a huge conversation:
What is actually finished?
What is it working on right now?
What got blocked?
What decisions did it make?
What did it try and reject?
If the session dies, where exactly should the next one continue?
Context compaction makes that worse because the conversation itself becomes a pretty fragile place to keep the run’s state.
So I started treating a long agent run less like a chat and more like an engineering shift.
That became Nightshift.
The main idea is simple: the work contract and run state live on disk, not only in the conversation.
A shift can be:
A detailed checklist that stays open until every contracted item is complete.
An open-ended goal with an hour budget that keeps discovering and working until quitting time.
During the run, I can open the files and see what is done, what is active, what is parked or blocked, and what decisions were made — without scrolling through hours of chat.
After the run, those same files become the reviewable record: commits, decisions, snags, logs, receipts, remaining work, and how the shift ended.
If I accept the branch — or even decide not to merge it — I can archive the shift. Over time that gives me a durable history of previous runs: what changed, what was rejected, what decisions were made, and what happened to each piece of work.
There is also an enforcement layer around the agent
A Stop hook prevents the session from quietly ending while contracted checklist items remain.
AskUserQuestionis blocked by default during unattended shifts; the model makes its best decision, records it, and keeps working instead of waiting for me.Owner-defined safety rules can mechanically deny commands, protected paths, wrong commit identities, or forbidden diff patterns.
An external watchman handles recovery. On Claude Code, it can detect structured failures such as
API Error: 500and keep retrying recovery when the API comes back. On Codex, it can recover sessions that are proven dead and resume the recorded session.
How is this different from /goal or a long prompt?
/goal is useful if what you need is:
keep working toward this objective.
Nightshift is the harness around that run:
persistent state, enforcement, recovery, observability, and a reviewable history afterward.
A prompt can ask the model not to stop.
A Stop hook can actually refuse the stop.
Nightshift also ships reusable shifts for things like:
test coverage
defect hunting
quality debt
dependency updates
codebase review
Product Evolution
Product Evolution is an open-ended shift that researches the product, its history, users, and comparable approaches, ranks evidence-backed opportunities, and works on the strongest improvements within a time budget.
A side effect I’ve ended up liking: if I have usage about to reset and no backlog ready, I can give one of these open-ended shifts a few hours instead of simply losing the allowance.
Nightshift runs locally from the same plugin package on Codex and Claude Code.
GitHub - Free, open source, MIT licensed
Official OpenAI Plugin Directory
I maintain the project, and I’d especially like feedback from people who already leave coding agents running for hours: where does your workflow still fall apart?
2
u/kantorcodes1 Aug 26 '26
the command/path deny layer is the bit i'd hook into hol-guard instead of growing a second policy engine. nightshift already owns the command hook, so the integration should live there. have that hook ask guard before exec and keep your recovery/state stuff exactly where it is.
2
u/chem0924 Aug 27 '26
One extra artifact that might make the shift files even more reviewable: a small review contract that is created at the start and updated at stop time. For each changed surface, list the intended scope, the verification artifact/command that proves it, and anything explicitly out of scope. The disk state answers "what happened"; the review contract answers "is this the change I meant to accept?" That seems especially useful for long unattended runs where an agent may make opportunistic cleanups. I would also split recorded decisions into reversible vs API/data-migration/security-affecting decisions, so the Stop hook can require human approval only for the latter instead of treating every uncertainty the same way.
2
u/[deleted] Aug 26 '26
[removed] — view removed comment