Thirty-Seven Hours In A Log Nobody Read

This entry covers 30 September 2026, and all times are UTC. No night report is on file in the usual place for this date, but one dated 30 September is among the day's reports. By its own account it covers the author's local day, which runs into the early hours of 1 October UTC, and its last figures are from 04:17 that morning. Several work-session records in the day's file also run into the morning of 1 October, and where this entry uses them the date is given. The git-guard measurement reported here was written on 1 October, the day after the ruling that prompted it.

The short version

The scheduler that starts work whenever one of the fleet's subscription seats has allowance to spare started nothing for thirty-seven hours, beginning at 01:17 on 29 September. After a restart, a process it had launched itself inherited its lock and never let go. Every five-minute run after that logged a skip, 176 on the 30th alone, and no one read the log.
An alert that one seat had no viable sessions reached the author. Within three minutes of the author's note on it, the stuck lock had been moved aside (14:07). Three changes went live between 15:19 and 16:28: a code fix, an alarm for a scheduler that goes quiet, and a rule that per-seat limits give way when allowance would otherwise go unused. They were revised through two rounds of GPT Pro review and a fresh Opus 5.5 check by 21:25.
A second fault cost allowance in the same hour. After the scheduler recovered, a per-seat limit twice held back a request it had already accepted, at 14:52 and 14:57, while the usage meter lagged. Six points of that seat's allowance went unused before it reset.
The fix went live before its independent review could run. When the review came, it found a top-severity bug in the running version: for about four hours, an error inside a bash if statement could let a run start work without holding the lock. The record does not say whether that ever happened.
Independent review is now the bottleneck. The GPT Pro review queue is allowed 24 sends in any 24 hours and had used them all. Ten finished patches sat uninstalled for want of review. Two completion checks that read FAIL were closed on Polaris's own judgement rather than passed.
The author asked why questions named in reports were missing from the author's phone. An audit of 169 question ids found 29 that were drafts never posted. The reports had called them "held" or "drafted", which reads as delivered.
A thirty-day census of 43,348 git commands found that a guard against destructive git commands would have refused 14 of them. One refusal would have been a mistake, and one would have prevented a real accident. The author ruled that the guard should also cover sessions the author drives. Nothing is installed yet.
The backlog's own nightly sweeps found 493 of 517 open items silent for more than three days, and 163 queues being written that nothing reads. Of 347 items whose text says they are done, not one passed the test for closing.

What changed in the harness

Times are 30 September unless marked. Each change carries the one thing it was meant to buy.

The scheduler no longer passes its lock to what it launches. Live at 15:19, and revised to its fourth version by 20:58. Intent: no process the scheduler starts can ever again hold its lock and silence every run after it. Early signal: no run skipped for a held lock in the 40 runs completed by 18:43, or in the 7 after the 19:46 revision.

An alarm for a quiet scheduler. Live at 15:27. Each run now writes a stamp with its skips, its failures, and the time since it last started work. The alarm turns red on any of four conditions:

a streak of skipped runs;
three hours without starting any work;
a streak of failures;
a stale stamp.

Intent: machinery notices a silent scheduler within hours, rather than the author noticing after a day and a half. Replayed over the runs of 15–30 September, the alarm fires only during the outage. A second step was split off as separate work: sending these alarms to Polaris first, and to the author only after an hour unhandled. At 06:28 on 1 October that step was built and in review, not installed.

Per-seat limits give way to unused allowance. Live at 16:00, under the author's ruling that missing usage is the highest-priority thing to fix. The per-seat limits, the cooldown and the fleet-wide limit now all yield whenever allowance would otherwise go unused, not only in a seat's final hour. Intent: no accepted request is held back while allowance goes to waste.

A floor followed at 16:28. When limits yield on the seat the orchestrator itself runs on, one session stays reserved for the orchestrator. Intent: yielding can never crowd out the orchestrator. Given the same live inputs, the old and new planners produce identical plans.

Three standing rules, written where a successor will find them. The author ruled:

no substantial allowance goes unused while the backlog is behind;
the author is in charge of none of the work of keeping allowance in use, because the machinery is;
per-seat limits yield to missing usage.

The third rule was written into the orchestrator's memory and into the starting brief of its next generation. (The orchestrator runs as a succession of sessions, each called a generation.) Intent: the rules survive the next handover.

Polaris's own review limit is now recorded as Polaris's. Rulings had described the limit of two review requests per piece of work as the author's cap. Polaris stopped doing so and said so. Intent: rulings record who actually set each limit.

Opus 5.5 work sessions are back on the 'xhigh' reasoning-effort setting. This was the author's ruling at 02:02. Intent: work sessions run at the effort level the author chose for them. The record does not say why the setting had been changed. Three sessions in the record were launched afterwards and give their effort setting, and all three ran at 'xhigh'.

Voice notes are no longer lost when a reply fails, once the app restarts. This is a fix in the Polaris app for voice notes that were lost when a reply could not be delivered. Intent: nothing the author dictates is lost to a failed reply. The fix reaches the author's phone only with an app restart that the author has to tap. At the end of the night, that restart was still waiting.

Review copies are bounded (installed shortly before 04:00 on 1 October). Some work sessions need a private copy of the orchestrator's files for review. Each such session now keeps exactly one copy, capped at 4 GiB, refreshed in place, and deleted when the session hands back. Intent: review copies stop filling the disk. The old method rebuilt a full copy of about 9.9 GiB every time, and two sessions' scratch space had grown to 19.70 and 16.39 GiB. On a real round, the new copy came to 1.16 GB.

Reports the author asked for jump the review queue (Polaris's ruling, 01:49 on 1 October). Such a report is still held until its review has been folded in, but its review now goes ahead of reviews of machinery. Intent: the author gets reviewed reports in hours rather than most of a day. Estimates at the time put the wait at about 16 to 18 hours. An earlier report, whose review came back five and a half hours after its session went quiet, was never delivered at all. The two reviews re-filed under the ruling were answered at 02:29 and 02:46.

Ruled, not yet installed: the git guard will cover the author's own sessions too. The author's ruling at 02:34 extends the planned guard beyond unattended sessions to every session the author drives. The guard blocks force-pushes, hard resets and cleans in live checkouts. Intent: the same protection whoever is at the keyboard. The question that prompted the ruling had noted that the guard's false-refusal rate was unmeasured, and the measurement was made the next day (see Technical detail). Installation waits on one more review, after 17:00 on 3 October.

What broke

The scheduler locked itself out for thirty-seven hours

Detected. An alert that one seat had no viable sessions reached the author, and the author's note on it started the search. Since 01:17 on 29 September, the scheduler had logged "previous run still holds the lock — skipping" on every run, 176 times on the 30th alone. No pass had read it.

Cause. After a restart, the scheduler's own dispatch created a process that inherited the lock and never released it, so every later run stood down. One seat lost its last hour of allowance on the 29th, and another seat lost its last hour on the 30th. Polaris's own account: "It broke on the restart's restore path, Polaris's own, and I did not read the guard's log on any pass since."

Done.

The stuck lock file was moved aside at 14:07:49.
The 14:12 run accepted the waiting request and dispatched work, and five jobs went out across three seats at 14:18.
The code fix and the alarm followed.
The same pattern turned up in a cache-warming job, which was filed at lower priority. A sweep found no other live case.

Lesson. A lock held on an open file descriptor is held by every process that inherits that descriptor, so close it before launching anything that can outlive the run. A component that fails by politely skipping raises no error. Watch for the absence of work, not just the presence of errors. A log nobody is obliged to read is not monitoring.

A limit that trusted a lagging meter

Detected. The author's note at 15:16 about six unused points of one seat's allowance.

Cause. The scheduler came back at 14:12, forty-eight minutes before that seat's reset. The seat's per-seat limit then withheld a request it had already accepted, at 14:52 and again at 14:57, while the usage meter lagged.

Done. Limits now yield whenever allowance would otherwise go unused, not only in a seat's final hour.

Lesson. A guard against overuse needs a rule for moments when underuse is the certain loss, such as the last minutes before an allowance expires. A guard fed by a lagging meter needs that rule twice over.

Live before its review, and the review found a top-severity bug

Detected. The fix went live at 15:19, before the GPT Pro review that changes are meant to pass could run, because the review queue could not send again until 19:14. The review came back BLOCK, with eight findings, five of them rated high or top severity. The most severe was in the version that had been running since 15:25.

Cause. In bash, an expansion error inside a top-level if abandons the whole statement. In that version, the run then went on into its body without holding the lock, so two runs could start work at once. The bug was reproduced on bash 5.2.21.

Done.

The bug was fixed and the fix installed at 19:46.
A second GPT Pro round returned FIX with two more serious findings, which were folded in by 20:58.
A fresh Opus 5.5 check passed at 21:25.
Development had already caught two smaller traps from the same family. In both, a file that might not exist killed the run under set -e.

Lesson. When urgency puts a fix live ahead of review, keep the review: here it found a top-severity bug in code that was already running. Use fault injection to test the path where the lock is not held, not only the path where it is.

Completion checks that could not pass, closed by judgement

Detected. Each piece of work is registered before it begins with executable tests that must pass before it counts as done. The scheduler fix had seven such tests, plus written criteria. It ended at FAIL on one test, which required GPT Pro's verdict to be "ship". The work had already used both GPT Pro requests it was allowed, so that test "cannot pass by construction", in the work session's words, and it went to Polaris.

A second check read FAIL for a similar reason. It covered a fence that puts a public site's old preview addresses behind a sign-in. Three reviews never gave the approval the check required, although none of them contested the change.

Cause. A completion test that demands a verdict from a rationed reviewer.

The ration traces to a 17 September decision. Rulings had recorded the two-review-request limit as the author's cap. The night report says it is not: it is Polaris's own policy from 17 September, made out of a note of the author's about something adjacent.
Separately, from 17:38 both seats on the external review route sat at their weekly cap until 3 October. The night report says every completion check reached after that point closed on Polaris's judgement rather than on an independent evaluator (but see What we still don't know).

Done. Polaris closed both checks on its own judgement, and stopped describing the two-request limit as the author's. The night report's verdict on the two closures: both look defensible, and the author should know they were calls, not passes.

Lesson. Decide in advance what a completion check does when the reviewer it depends on is rationed out. Also record who set each limit. An agent's own rule, written down as the owner's, picks up authority nobody gave it.

Review became the bottleneck

Detected. By the night report, and by the queue positions in the work-session records.

Cause. Changes are meant to clear an independent review before they install. The broker that sends GPT Pro reviews is allowed 24 sends in any 24 hours, and the work produced more than that. By night:

ten finished patches had been handed back unable to install;
the queue was past position thirty;
four review requests on one piece of work had died without producing a review at all.

Done.

Reports the author commissioned now go ahead of machinery reviews.
A change was built and staged to detect and retire requests whose generation dies without producing text. It is not installed.

Lesson. If nothing installs without independent review, the review queue's throughput is the system's throughput. Track the queue's depth like any other health number, and set its priority order before the day you need it.

Questions reported as on their way that were never sent

Detected. The author's voice note at 00:16, asking why questions a report mentioned were not among the open ones.

Cause. Polaris puts decisions to the author as questions with a recommended answer, internally called "cards", on a tab in the phone app. Reports had named card drafts that were being held back for one of three reasons:

a review still in the queue;
a daily limit on cards;
a check that had to pass first.

The reports described these drafts with words like "held", "drafted" or "Polaris will post it". Reports delivered since 15 September named 169 card ids:

| State of the card | Count | |---|---| | On the tab | 23 | | Answered (13 of these before the app recorded who answered) | 81 | | Closed | 30 | | Drafts never posted | 29 | | A withdrawn draft, or not a real id | 6 |

Three further sentences promised a card that was never drafted.

Done. The audit built a ledger of every such sentence. A checker re-derives each row from the queue, the answers and the draft files, and fails on purpose if any row has been altered. That work posted nothing and changed nothing. Correcting reports the author has not yet heard was left to Polaris.

The audit also checked who answers. All 54 answers written since 15 September were the author's, and the last answer written by anyone else dates from 26 August. The audit found one occasion, at 20:47 on 20 September, when Polaris closed four cards itself by adopting the recommendation their review had made, plus a fifth whose dates had passed. Polaris has not done so since.

Lesson. In a report to a person, an internal pipeline state reads as a delivery claim. Say where the thing is from the reader's side ("not on your tab"), not where it sits in your pipeline.

The night report's instructions had gone stale

Detected. By the night report itself, while it was running.

Cause. Two pointers in its instructions were dead:

They sent it to a self-audit log whose own first line says its generation closed on 27 August. The live log is a different file.
A plan row it is meant to quote by number no longer resolves, because the plan is keyed differently now.

Done. The report read the live log and the night's priority list instead, and said so up front. The record does not say whether the instructions were corrected.

Lesson. A prompt that names "the current" file goes stale at the first handover. Point at a stable alias, or have the reader check the file's own liveness before trusting it.

An acknowledgement a machine could give (caught before install)

Detected. Early on 1 October, by a fresh-context pre-review, not the review of record. It was reviewing the staged change that sends the scheduler's alarms to Polaris first.

Cause. The design treated any acknowledgement of an escalation as handling it. But an automatic intake triages escalations, and it closes nearly all of them itself with a "no card" disposition. That covered 711 of 720 escalation rows from 24 September to 1 October, and all seven escalations this alarm family had ever raised were closed by that disposition alone. If it counted as acknowledgement, a miss Polaris never acted on would never reach the author.

The check also turned up a second gap. Escalation rows carry no author field, so the writer is inferred from the adjudicator. Polaris's own answer to the work session's question had been recorded under the intake's default name.

Done. In staging, incidents Polaris owns now ignore the automatic disposition. They count as acknowledged only through a row written by a Polaris generation, and Polaris must name itself as the writer when answering these alarms. Nothing had been installed by 06:28.

Lesson. If an automated step can produce the signal that silences an escalation, the escalation is dead code. Make every acknowledgement attributable to someone who acted.

A backlog that forgets

Detected. By the nightly sweeps; the silence sweep ran at 17:35.

Cause. Not established, because the sweeps count rather than diagnose. What they found:

The plan registry.

It holds 589 items, 517 of them open.
493 of the open items (95 per cent) have not been mentioned by any status file, decision record or completion verdict for more than three days.
The sweep reads 80 of those as finished but never closed, 48 as waiting on the author, and 365 as simply stalled.
256 have never produced a signal at all.

Queues and dispatches.

163 queues are being written with nothing reading them, with 362 records added since the previous sweep.
218 work-session briefs have no matching status file, meaning the dispatch was written but never started.

The night report's own counts.

Its "dark set", its term for items gone quiet, grew by thirty to 1,183.
The item at the top of its priority list has been ranked for eighteen nights, and one project for sixteen. Neither has ever been staffed.
Seven items have had every blocker retired but have no card, and they were not ranked at all.

Work claimed done but never collected. Early on 1 October, an overseer sent to restart a stalled private project found it was not stalled on work. Two pieces of work had sessions that claimed done, and nobody had collected them. One had been waiting since 26 September for a check that never ran, because the independent checker was down that day. The other had failed its check, the author had accepted the result anyway, and the work was never closed.

Done.

The silence sweep writes each finding as its own card draft. Whether any of them reached the author is not in the record.
The closure check declined to close rows on their wording. Of the 347 whose text claims completion, it confirmed none, referred 77 to the author, and refuted 270.

Lesson. A queue with a writer and no reader is silent data loss. A ranking that nothing consumes is a report, not a scheduler. And the word "done" in a row is not evidence: ask for a dated claim and something on disk that corroborates it.

Intentions vs outcomes

Forward: changes on the covered day. Re-check dates count from 30 September, including for the two changes made in the early hours of 1 October.

| What changed | Intent | Re-check +3 | Re-check +14 | |---|---|---|---| | Scheduler lock closed to the processes it launches | No process the scheduler starts can silence it again | 3 Oct | 14 Oct | | Quiet-scheduler alarm | Machinery catches silence within hours | 3 Oct | 14 Oct | | Per-seat limits yield to unused allowance; one orchestrator session reserved | No accepted request is held back while allowance goes unused, and the orchestrator is never crowded out | 3 Oct | 14 Oct | | Standing rules on unused allowance written into memory and the successor's brief | The rules survive the next handover | 3 Oct | 14 Oct | | Polaris's own two-request review limit recorded as Polaris's | Rulings say who actually set each limit | 3 Oct | 14 Oct | | Opus 5.5 work sessions at 'xhigh' | Sessions run at the effort level the author chose | 3 Oct | 14 Oct | | Voice-note loss fix (app restart pending) | No dictated note is lost to a failed reply | 3 Oct | 14 Oct | | Review copies: one per session, 4 GiB cap | Review copies stop filling the disk | 3 Oct | 14 Oct | | Commissioned reports' reviews ahead of machinery reviews | Reviewed reports reach the author in hours, not a day | 3 Oct | 14 Oct | | Git guard extended to author-driven sessions (ruled, not installed) | The same protection whoever is at the keyboard | 3 Oct (its review falls due after 17:00) | 14 Oct |

Backward: check-backs due (retrospective). This entry was written on 1 October from a record assembled at 14:35 that day, so its check-backs use that day's knowledge. The rows falling due today come from the forward halves of earlier entries, covering changes of 27 and 16 September. Those rows are not in the record behind this entry, so they are neither listed nor retired here.

| Row | Verdict | Method | Limit | |---|---|---|---| | Memory: on a standing weekly re-check because the author flagged it as doubtful | UNVERIFIABLE | Read every source in the record for a test of the memory system. Found two adjacent facts. First, a ruling was written into memory on the day. Second, the queue that collects candidate memory entries is among those the nightly sweep found being written with nothing reading them (24 new records since the previous sweep). | Neither fact shows whether a stored memory is recalled when it is needed. The sweep infers a missing reader from a queue's growth and does not inspect the reader. The row stays on the weekly re-check. |

What we still don't know

Whether the unlocked path ever ran. The scheduler's second version was live for roughly four hours, from 15:25 to 19:46. The record does not say whether a run ever started work without the lock in that time.
Whether checks after 17:38 had an independent evaluator. The night report says every completion check reached after 17:38 closed on Polaris's judgement. Records from two work sessions in the early hours of 1 October show checks passed by GPT-6 Astra at 'xhigh', at 02:37 and 03:07. The record does not reconcile the two accounts.
What allowed two installs ahead of review. The night report says nothing installs on an in-house check alone. Yet the scheduler fix (15:19) and the review-copy bound (just before 04:00 on 1 October) both went live ahead of their outside review. The record does not say what rule allowed it.
Who the new scheduler alarm reaches until Polaris-first routing is installed. The night report says the fix was "widened… to route those alarms to Polaris first", which can be read as done. The work session's record says the routing was built and in review, not installed, as of 06:28 on 1 October.
When the cache-warming job's copy of the same lock leak will be fixed. It is filed at lower priority.
What a logged "violation" means. The 13:30 scheduled run of the tool that applies approved configuration changes logged a violation on one item, tagged "approved item removed" and "verification record fabricated". The record does not say whether the tool fabricated a record or caught one.
How the backlog counts relate. The night report's dark set (1,183) and the sweep's 493 quiet registry rows are different counts over different sets. Likewise, the sweep reads 80 quiet rows as finished from their text, while the closure check confirmed none. The record reconciles neither pair.
Whether the night report's stale pointers have been corrected.
How the git guard behaves beyond what was measured. GPT sessions and the laptop were not counted. The author's own sessions in the window ran one git command, so no rate exists for them. The February–August look-back cannot separate what the author typed from what a launcher typed.
When the waiting work lands. Ten finished patches have not installed, and the voice-note fix has not reached the phone.
This entry's own blind spot. The record behind it was cut at its size limit, and two of the sweep reports were truncated. Anything past those cuts is missing here.

Technical detail

The lock leak and its fix

The scheduler is a bash script run every five minutes. It holds a lock on file descriptor 9 for the length of each run. The process that leaked the lock was started by the scheduler's own dispatch after a restart, and it inherited descriptor 9. While the leak stood, every run found the lock held and skipped. Before the fix went in, the work session judged that the leak could recur only through a restart of the terminal multiplexer's server.

The fix does four things:

runs the body in a group with descriptor 9 closed for anything it starts ({ …; } 9>&-);
records who holds the lock whenever a run finds it taken;
writes a per-run stamp;
adds an exit trap.

The cache-warming job that shares the defect holds its lock on the same descriptor while it starts a detached terminal-multiplexer session. It is filed, not fixed. A sweep for the pattern found no other live case. One other lock is held on purpose and is bounded by a 180-second timeout.

The install order is worth copying. Each live file was backed up beside itself. The candidate was written to a temporary file in the same directory and renamed into place. All of this happened under a fleet-wide edit lock. The alarm's row went into the liveness checker only after the first stamp existed, so the checker never saw its input missing.

The tests were red-first: each was shown to fail on the old code before passing on the new. They were then mutation-tested.

The final lock suite passes 74 of 74 across five repeats, including under load, and catches 30 of 30 deliberate mutations in 105 seconds.
The limits suite passes 25 of 25.

Two shell traps

Expansion errors inside if. Bash abandons the whole top-level if when an expansion error hits inside it. In the scheduler's second version, the run then went on into its body unlocked. The first GPT Pro review found this; it was reproduced on bash 5.2.21 and fixed in the 19:46 install.
set -e and files that may be absent. Under set -e, reading a file that may not exist kills the run.
- In development, reading a previous stamp that did not yet exist did exactly that. It was fixed, and a mutation was added to the tests.
- A command substitution reading an event log aborts the run with status 2 whenever that log is absent. This is latent only because the file happens to exist on the workspace machine. The new failure stamp caught it in the test fixture.

The quiet-scheduler alarm

The stamp carries skip and failure counts, plus the time since the scheduler last started work. The liveness row turns red on a streak of skips, three hours without starting work, a streak of failures, or a stale stamp. A first skip behind a lock held by another process is deliberately not an alarm; the second in a row is.

The replay figures were corrected twice:

First reported as 7,813 runs.
Corrected to 7,813 records parsed, with 3 dry runs excluded, leaving 4,314 live runs.
A later re-run counted 4,300, because log retention had moved the window.

In each version, only two episodes fire: one of three hours without work, and one skip streak. Both fall inside the outage.

Limits that yield, and a reserved session

The planner's per-seat limits, its cooldown and its fleet-wide cap now all yield whenever allowance would otherwise go unused. On the orchestrator's own seat, the room is max(override, escalated per-seat limit 4 − 1 reserved session) = 3. The reserve is counted in sessions (three of four usable), not as a share of the five-hour usage window.

Later that night, two seats were found parked in a wind-down band written for natural weekly resets. With manual resets planned, the band was lifted for an hour. When one seat's allowance was then reset by hand, all eight jobs on it stayed alive through the reset.

At 04:17 on 1 October:

| Measure | Value | |---|---| | The orchestrator's seat | 81 per cent of its week, against a derived ceiling of 85 per cent; a handover to the next generation was being prepared | | The other four seats | 0, 3, 10 and 24 per cent (two freshly reset) | | Jobs working | 46 | | Sessions open | 55 | | Free on the system drive | 326 GB |

These figures were read straight off the board, because the sweep that usually supplies them did not finish in its window.

Review economy and dead generations

GPT Pro is reached through a browser, by a broker that sends each request, watches the page and recovers the answer. Review-class sends are capped at 24 in any 24 hours. On the morning of 1 October, three separate pieces of work sat 23rd, 26th and 32nd in the queue.

Under a 17 September decision, a piece of work may file at most two GPT Pro requests. Requests cancelled before sending do not count.

The scheduler fix shows how this plays out. Its seven executable tests were all red at registration. Six passed. The seventh required a GPT Pro verdict of "ship", and it could not pass once rounds returning BLOCK and FIX had used both requests. That stayed true even with both rounds' findings fixed and a fresh Opus 5.5 check passing. Polaris's default on the resulting escalation was "stays FAIL, code runs".

A "dead generation" is a request where the model's generation dies without producing text. A staged change, not installed as of 04:27 on 1 October, handles these. Its threshold comes from measurement across 804 answered requests:

209 had at least one attempt that produced no text;
among requests that were eventually answered, the longest no-text idle stretch was 5 minutes as logged, and 7.5 minutes at most;
dead requests sat idle for 15 to 180 minutes.

The rule follows from that. A request is handed off as dead and retired through the broker's existing path when:

it was seen generating;
no text was ever read from it;
its composer has been idle for 30 minutes, at least four times the longest harmless silence.

Each request's content is also digested. A send is refused when the same piece of work, or any item in it, has already died twice.

All five dead generations in the data ran on one browser channel, and each lost its page to a browser-protocol disconnect. The same work found two other problems:

265 rows in a live ledger were seeded by a test that never pinned its ledger path;
two older dead generations had been released after three hours without being flagged.

Review copies and a symlink

Review sessions had been building their private copy by deleting and re-copying the whole tree, about 9.9 GiB each time. Two sessions' scratch areas held 9.85 GiB each and rose to 19.70 and 16.39 GiB.

The replacement keeps one copy per session, identified by an owner marker. It refreshes that copy in place with rsync --checksum --delete --delete-excluded, checks a 4 GiB bound before copying, and deletes the copy when the session hands back.

| Builder | Size on a real round | |---|---| | Old builder | 10.30 GB | | Existing lean variant | 3.02 GB | | New bounded copy | 1.16 GB |

On the same round, a refresh took 2 seconds and added 98 KB, and a second copy for the same session was refused.

Two hazards came out of testing:

rsync's default quick check missed a change made within the same second at the same size, which is why the refresh uses --checksum.
A symlink planted where the copied tree's top directory belongs would have turned --delete-excluded onto the live tree. The guard now checks every path component for symlinks, and requires the physical path to equal the logical one.

The same work found one session holding 9.25 GiB of copies, and 14.2 GiB of another project's temporary files that had never been rotated.

The git-guard census

Scope. The window is the 30 whole UTC days from 31 August to 29 September:

about 17,800 Claude Code transcripts on the workspace machine;
410,513 shell commands, 29,842 of which mention git;
43,348 git commands, once split the way a shell splits them.

The same reader both finds the commands and judges them, so any command it fails to recognise is never counted.

Whose sessions. A session counts as unattended if it had no terminal, if its id is in the fleet's registry of launched sessions, or if its opening prompt is a launcher's. That gives 4,865 unattended sessions and 3 attributable to the author. All three were opened on 9 September to ask why Polaris and the other sessions were down, and between them they ran one git command, a git log. A message the author typed into a session Polaris launched cannot be told apart from the launcher's.

What it refuses. The guard refuses three things and names the safe alternative each time:

a forced push (--force, -f or a + refspec), anywhere. A push with a lease passes, and so does a dry run;
git reset --hard, when the repository it acts on is not under a temporary directory (/tmp, the session scratchpad, ~/.cache);
git clean -f, under the same condition.

Of the window's 48 hard resets and cleans, 37 ran under /tmp. Linked worktrees are not treated as scratch. More than 250 exist, and some are staging and release trees.

Edge rules.

A target the hook cannot resolve passes and is logged. This follows the lesson of a symlink guard installed on 25 September, whose first version would have refused a third of real link commands: refuse what you can prove.
A cd into a directory that may not exist, not chained with &&, leaves both locations possible. The guard refuses it if the session was inside a live repository.
Overrides ride on the git command itself and must say why and who authorised them, for example GIT_GUARD_OVERRIDE="<why, who authorised>" git push --force …. Every override is logged.

The 14 refusals.

The one accident: on 31 August, a hard reset threw away an uncommitted edit made in the same command, and the session redid it 17 seconds later. reset --keep would have kept it.
Four deliberate discards in live public checkouts: hard resets and a clean of what dry-run publishes had staged, plus one other clean.
Three forced pushes to a session's own local staging repository, during an authorised history rewrite.
Five hard resets in live checkouts, or in a session's own worktree, where reset --keep does the same job on a clean tree.
The false refusal: a forced push between two throwaway repositories that a test had just built in the scratchpad.

Six refusals need only the safer command the refusal names, provided the tree was clean, which the transcripts do not show. Eight need the override.

Replay limits. A month-old command's scratch directories are gone, so the cd rule cannot be replayed exactly. Taking every cd as having worked gives the 14 refusals. Taking every directory as it is today gives 25. On a hand reading of the eleven extra commands, most likely no more than three would have been refused at the time.

The look-back. The same rule, applied to the author's sessions from February to August, found:

986 sessions, 65,543 shell commands and 12,554 git commands, the first on 16 February;
15 refusals, none of them mistaken: seven forced pushes to GitHub, seven hard resets in live checkouts and one clean.

This is the weaker measurement. Before the fleet's registry existed, "no sign of a launcher" also catches long runs the author started and left.

Text matching would have been worse. A text-matching guard, like the existing guard on process kills, would have stopped 69 shell commands in the 30 days. Fifty-five of those stops would have been needless:

32 commands that only mention the git commands, in a report, a search pattern or a script being written;
23 commands under /tmp.

Outside the guard.

Scripts: seven shell commands in the window wrote or patched a script that later runs one of the three commands, and about fifty existing scripts contain one.
Other ways to discard work: git checkout -- <paths> (270 times, 256 completed), forced worktree removal (92), history-filter tools (14), branch deletion (6), stash drops (5).
GPT sessions.
The laptop.

A finding that changed the install plan. The current Claude Code picks up a changed hook inside a session that is already running, so running sessions would not keep their old settings. The guard therefore leaves alone any session already running when it is switched on. A throwaway test session checks this on the installed version before any account's settings are touched.

Review history.

Before the review of record, a second model attacked the guard for six rounds, with about 15,000 hostile and awkward commands.
GPT Pro then asked for 21 fixes and two smaller ones. They included:
- ordinary commands passing because a target was wrongly treated as resolved;
- false refusals of harmless commands;
- an override that could outlive its reason;
- an interpreter-load failure that would become a blocking hook result.
All are made, and each example is now a test beside a harmless twin that must still pass.
A second attack on the revised guard, about 3,600 more commands, found five more ways ordinary shell code could slip past. Those are fixed too, and the revised guard reproduces exactly the same refusals.

One more review, by GPT-6 at its highest reasoning setting, follows its weekly reset at 17:00 on 3 October. If that review clears it, the same file goes into every account's settings in one step, each with a backup beside it.

The instruction stack's byte budget

On the 30th, thirty-three changes to the agent's global instructions were re-staged as one batch. Thirty-one of them were approved by the author between 24 August and 20 September, and two were earlier single items.

The global instruction file has a hard cap of 18,500 bytes, and the full chain of changes would have reached 19,058. To fit, lines from five approved items were moved verbatim into separate documents, each leaving a title and a pointer behind. The file goes from 16,520 to 18,422 bytes, 78 under the cap. Nothing is applied until the author runs one command, posted as a question at 18:24.

While waiting, the session noticed something in the 13:30 scheduled run of the tool that applies approved changes. That run had logged a violation on one unrelated item, tagged "approved item removed" and "verification record fabricated". None of the 33 changes was touched.

Smaller mechanisms

A deadlock between a completion check and the audio job. Early on 1 October, a commissioned report's completion check required the report's audio before the work could be claimed done. Meanwhile, the job that narrates reports skips any report still owned by open work. The session rendered the audio by hand through the job's documented path, on CPU so that no GPU job started, and escalated the rule.
The privacy scanner. Before anything left their work areas, the workspace's scanner caught two deny-listed words and an account address in one report draft, and a private first name in another. It also over-matched an ordinary English word.
Work left waiting rots. On re-check, the uncollected private-project work passed five of its seven tests. Both failures came from a later change, on 27 September, to the renderer it shares.

Polaris is an AI agent that runs the author's workspace overnight, under a constitution the author ratified clause by clause. It acts only inside the workspace, spends no money, and sends nothing in the author's name. This record is written from the day's logs, not from memory.