A refusal could be thrown away while an earlier one was being written

[jorgemanrubia]

A refusal Codex wrote could be thrown away — recorded nowhere, not merely missing from a turn's result. The read end of the worker's output was released a couple of seconds after the worker was terminated, whatever the goroutine reading it was doing, and closing it discards whatever the worker wrote that nobody has parsed. That goroutine is allowed to be slow: writing a refusal to the ledger is given ten seconds, and the driver's own contract puts that write on the reader, before the update for it is emitted. So the clock ran out inside a write and took the pipe away with the worker's next refusal still in it.

Carded as The worker's output pipe is closed on a clock, and a refusal can be lost with it, after being found and taken back out of An unsafe session could report fewer refusals than it made.

What was wrong was the unit, not the goroutine

The card proposed separating the pipe read from the ledger write so the reader would only ever read. I built that first and it does not survive contact with the contract it would have to break. driver.go says a refusal "is never held only in a session's memory", and that "the recorder is called before an update is emitted, so a worker that exits between a refusal and its result has already recorded it." A queue in memory is what that forbids; publishing the update before the write lands is the window it exists to close. It also buys nothing: the same writes still have to finish before the session's updates close — where the dispatcher anchors "every refusal the driver read has been through the recorder" — so moving them to another goroutine only moves which goroutine waits.

A ledger write moves no bytes. So the drain is counted in bytes, and the ten seconds a write may take cannot spend it. The write stays where the contract puts it.

The budget is derived, and against a bound that does not involve the scanner: a worker is ended before its reader is asked, so what remains of its output is at most one pipe's worth, and the budget is far more than a pipe holds on any system this runs on. The worker's own last lines are therefore never the ones cut off. Past the budget, what is still arriving can only be a descendant that left the worker's group and is writing without end — the one case that has no other ending, and one the connector had already decided not to wait for.

The pipe belongs to the reader while it is reading

Termination asks the reader to stop rather than closing the descriptor under it. The deadline on the pipe has one owner, so nothing can cut short a window the reader opened for itself. The descriptor is released when the reader says it is through, rather than on a timer that cannot know. And a cancel asks too: ending the worker is not the end of its output when a descendant holds the pipe open, so a canceled turn that only the reader can finish would otherwise never be finished.

Every path, and what happens when the budget runs out

path	what it does	on expiry
exec, when the process exits or after its wait delay	closes the write end	the reader drains what is buffered, then sees the end of file — nothing lost
asking the reader to stop	sets one field; touches neither the descriptor nor its deadline	—
the reader, once asked	reads until a window of its own finds the pipe empty, or the drain budget of bytes runs out	what a descendant is still writing is abandoned; never the worker's own output, which was all in the pipe before the asking and is far smaller than the budget
the Worker's release after termination	closes the read end once the reader says it is through; the old clock only where no reader registered	—
closing the output outright	closes the read end at once, discarding what is in it	now only for releasing a descriptor nobody is reading

What can end a turn is unchanged by this. The reader's own ending, turn.completed, turn.failed, and the unsafe or canceled endings reached from any of them are all the reader, after it has parsed the stream to that point. The policy check claims the turn before ending the worker, then waits for the reader. The prompt's writer can still finish a turn ahead of the reader, in both its branches, and needs a worker that stopped reading its input while still writing.

Where a refusal is recorded is also unchanged, which is the point: on the reader, at the moment it is read, before the update for it is emitted.

Evidence

The test makes its ordering rather than waiting for one: the second refusal is said only once the ledger is holding the first, so it is in the pipe and nowhere else — the reader cannot have taken it into its own buffer, because it was not there to take. The fake fails loudly if that trigger never comes rather than saying its events anyway. No assertion runs on a helper goroutine.

	without the change	with it
a ledger held past every clock in this path, with a refusal in the pipe	10 failures in 10 on main, the refusal reaching neither the ledger nor the result	0 in 5
a stop that closes the pipe	10 in 10	0 in 5
a drain counted in time rather than bytes	10 in 10	0 in 5
no budget at all, against a descendant writing without end	never ends, 3 in 3	0 in 5
a stop that installs its own deadline	20 in 20	0 in 5

go build ./..., go vet ./..., gofmt -l ., golangci-lint run --build-tags dev ./... and BASECAMP_NO_KEYRING=1 go test -tags dev ./... are all clean, as is go test -tags dev -race ./internal/connector/..., and so are GOOS=windows and GOOS=darwin builds.

[Copilot]

🟡 Changes recommended

The asynchronous handoff weakens refusal durability and does not reliably bound shutdown.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Separates Codex output reading from ledger writes to prevent refusals being discarded during shutdown.

Changes:

• Adds reader-owned pipe draining and shutdown signaling.
• Introduces a bounded refusal queue and scribe goroutine.
• Adds regression coverage for slow ledger writes.

[!TIP]
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

File summaries

File	Description
internal/connector/driver/worker.go	Adds reader-controlled pipe lifetime and drain deadlines.
internal/connector/driver/worker_other.go	Adds platform stub methods for the reader lifecycle.
internal/connector/driver/codex/codex.go	Moves refusal recording to an asynchronous scribe.
internal/connector/driver/codex/codex_test.go	Tests slow-ledger refusal preservation.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

The byte-based drain can block shutdown for hours and may truncate output from enlarged pipes.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (1)

internal/connector/driver/codex/codex.go:338

• The PR description still presents a reader/scribe split, bounded queue, and clock-based drain, but this revision intentionally keeps RecordRefusal synchronous on the reader and implements a byte budget with no scribe or queue. Please update the description and evidence so the architecture being reviewed matches this implementation.

	// The worker's output is released when this session has read it, not on
	// a clock: what the reader does between reads — writing a refusal to the
	// ledger — is allowed to take longer than any such clock.
	worker.ReadingDone(s.readerEnd)

• Files reviewed: 5/5 changed files
• Comments generated: 2
• Review effort level: Balanced