Recorded 2026-10-10 UTC for the scoped external-administrator repair requested by the operator. No paid model calls, subscription reserve changes, permission expansion or automation-stop override were performed by this repair.
Three native Codex Team accounts were blocked until November 1 although their included primary and secondary windows were available. Provider spend_control.reached=true described a zero paid-credit workspace limit; the engine treated that paid restriction as included-quota exhaustion. PR 9278, implementation 1101d4d9565065796a7a8866ab3856a383fcaee0, introduced a shared decision that permits native included usage only with complete fresh available windows. Missing, stale or exhausted evidence and actual provider rejection remain blocked. Exact obsolete spend-only blocks were migrated. PR 9293 retained mode-aware scheduling priority and validation coverage.
Repeated delivery attempts were cancelled by later development pushes. Installed Gitea 1.24.6 cancels prior runs sharing repository, ref, workflow and event, including workflow dispatch; concurrency settings do not prevent it. PR 9336, implementation be111cdf6546a8d641f2ce19a12de724831b34f2, requests delivery by atomically creating exact source refs delivery/candidate-<SHA> and delivery/production-<main SHA>. New sources have separate provider identities. Initial admission skips stale queued sources; already admitted development ancestors may drain while exact source tree, provider task, immutable artifacts, election and deployment claims prevent stale overwrites. Existing uncertain or failed requests do not cause blind duplicate submission.
Original capacity fixes reached candidate source 86ff99940575950e226200ac6e89ad518758aaec. Worker publication run 4411 built main 7e74853a44c289b9cbb867f15f08b71a995b62db; its tree equals that candidate. Published worker digest is sha256:6ef433a8c32b2896db2c2ace1066b99b57021185dea679b329a68bb8d6e0c336. All seven Running worker pods were Ready on the designated worker node with that imageID; the three affected account leases were live and online.
Pipeline repair source 8826117d11f66b7e01e54068921a08f13cf40132 passed configured-dev bootstrap run 4418, integrated to main as 17c74ac21f73c6a3f476f8228dc3cd3cd6560287 through PR9357, and reached TEST and production. Both external /healthz endpoints returned HTTP200 with source revision8826117d. Production bootstrap used the existing configured-main route after old production rejected the new source-ref authorization. Immutable production configuration contents and prepared contract 49ce8d92d63066e9929412f23b77fc3f292bb263d0c0175701b3bb8a1c0e9001 were independently verified; no ad-hoc runtime flag mutation was used.
At approximately00:35 UTC the authenticated website account API returned HTTP200. bechti44@gmail.com and work.julian.bechtold@gmail.com had100% remaining in both windows; julian@bechtold-consulting.ch had65% and95% remaining. All three returned capacity_blocked=false and capacity_next_probe_at=null; their workers were online with no active task. The API aggregate reported5 online and5 available Codex slots, zero busy. Subsequent worker quota refreshes retained the paid restriction while the shared included-usage blocker remained false. A preserved consulting-account native requirements task had been claimed after worker publication; it later ended as superseded, which is not successful product delivery.
Full autonomous pipeline acceptance remains open. The next preserved source 59469a85a34abcb27bd31ce6eaea4fe10beaa9c2, PR9358, entered the normal immutable-ref route in run4423. Validation stopped at the isolated categorization admission test because its updated fixture account differed from the account selected by the CI invocation. A one-line CI fixture correction is independently reviewed and undergoing worker PostgreSQL reproduction; no runtime paid-use or product configuration change is included. Green bootstrap deployment is not substituted for normal preserved-implementation delivery.
Tests passed on the designated worker:49 original capacity checks,25 scheduling/delivery checks, and pipeline repair14 dispatcher tests,3 real-Git integration tests, focused provider receipt test1/1, candidate shell contract, formatting and4 workflow YAML parses. Owned temporary execution resources were removed and storage stayed above the200GiB floor. Exact source/evidence checkpoints remain bounded under the administrator task temporary directory while acceptance is pending.
On a genuine validation failure repair its defect before requesting a new source. On uncertain dispatch state verify exact provider run/ref/task evidence and retain the source; use existing configured recovery only after proving the prior task terminal. For rollback retain the candidate ledger and immutable artifacts, respect delivery stops, and deploy only a previously validated authorized candidate. Do not force-push release refs or erase interrupted work. A separate monitor finding remains: its events label skipped jobs as success and cancellations as failure; authoritative provider status and logs are required when those labels conflict.
The isolated fixture repair PR9380 passed branch validation4429 and merged as development source e57ba46ef96d9660b66a78d801841dd01033c7e0. Normal immutable-ref candidate4431 passed validation, artifact acceptance and main integration; a 15-second read timeout during a repeated, read-only elected manifest lookup stopped TEST rollout. Failure reporting also rejected Gitea's empty run-attempt value. Engine-owned recovery4435 reused candidate e57ba46ef96d9660b66a78d801841dd01033c7e0-4431-1 without rebuilding; the authoritative TEST deployment receipt is healthy at 01:01:22 UTC. Both Ready TEST deployments and external backend/frontend revisions match e57ba46e and its stored image digests. The candidate's separate failed state records a production attempt ending before an execution claim; it does not invalidate the healthy TEST event.
The capacity API was rechecked: all three affected accounts remain unblocked with no scheduled recovery probe. Aggregate capacity is five online slots, one busy and four available. Existing paid restrictions and protected reserves remain unchanged.
A bounded follow-on receipt repair is independently reviewed in branch codex/candidate-receipt-resilience-20261010: retry only read-only manifest transport failures, leave uncertain mutating report outcomes to durable reconciliation, default Gitea's missing attempt to1 while rejecting explicit invalid attempts, and recognize the current superseded-manifest response. Worker verification and an uninterrupted normal candidate acceptance remain pending. Concurrent managed-product assessment configuration is outside this repair's spending authorization.
PR9393 repaired manifest timeout handling and the missing Gitea attempt value. Candidate4445 then passed validation and image assembly but hit an unstructured HTTP503 at receipt submission during a concurrent production restart; its downstream jobs were skipped, despite the monitor presenting them as successful. The blanket mutation retry restriction was too broad for the immutable CI receipt. PR9426 corrected that distinction using the existing server candidate-key and exact saved JSON replay checks, and moved exact-run artifact publication ahead of receipt submission. Independent review and eleven mocked boundary tests plus YAML parsing passed on the designated worker. Other ambiguous mutating requests still require durable reconciliation.
Normal immutable-ref candidate4449, source 91e4d950a23ce24b3a7bbca116972982644f4dd0, passed all four provider jobs: validation/build, exact artifact finalization, main integration and elected TEST deployment. Artifact4591 was published and read back at01:41:20 before receipt submission at01:41:29. TEST's healthy receipt was recorded at01:43:15.668731. Both Ready application pods' actual imageIDs match backend sha256:cef70b397359dea7a45411fcfe5bc8c75ea573d60a1fb7e487631385a16e63d2 and frontend sha256:6c5f41616f020aedcfb5137e9af5a9620a65bbfdbdfe4ddb2f7009ce24c814d2. External backend health and served frontend revision both match91e4d950. This proves an uninterrupted normal TEST delivery of the preserved development implementation through the repaired engine.
The normal website account API was rechecked at01:43:55: all three affected accounts remain unblocked with no next recovery probe. Capacity aggregate is six online slots, one busy and five available; one separately disabled slot remains disabled. No reserve, paid budget or permission changes were made by this continuation.
Main integration is 4357c1bafbf4b9df3859514e373c282b66aeaba1. Automatic production run4451 timed out on its single30-second authorization POST and left no production decision or claim. Production remained healthy at the previous source959a10c7. Provider branch/tree/tasks reads were then measured at0.07/0.06/0.12seconds, with no active promotion task and unchanged enabled standing delivery policy. One governed workflow-dispatch recovery4454 was requested on exact current main for the same candidate, reusing its images. It is pending; no duplicate candidate build or ad-hoc deployment was used. The main change relative to deployed source consists only of four CI workflow/script files; runtime configuration is unchanged.
Bounded separate findings remain: the native monitor incorrectly maps skipped jobs to success; candidate insertion and proven-ancestor recording are separate database writes, so identical receipt replay does not prove their atomic completion. Preserve these findings without claiming they are fixed. If the supervised production authorization times out again, investigate effective server/proxy request bounds before another dispatch.
The first supervised recovery4454 completed authorization but its backend rollout failed: the container repeatedly failed liveness before startup completed. The workflow restored the previous production pair, then its rollback receipt met an unstructured HTTP503. A concurrent administrator repair added a repository-backed startup probe (60 attempts at10seconds), evidenced in the assessment repair's backend-startup-probe.json, applied at02:02:38. This repair did not overwrite that change or replay a stale rollback receipt.
The engine itself reserved and dispatched recovery4456 at02:07:10, claimed provider task19437 with execution 9630-edc6e840-b9d3-41f7-abc9-194fa3a33005, and reused the exact candidate4449 image pair. Run4456 succeeded. The production ledger is production_live; its healthy receipt was recorded at02:12:50.790128. At02:13:56 both TEST and production external health endpoints returned HTTP200 with source 91e4d950a23ce24b3a7bbca116972982644f4dd0, and both served frontend build-revision files matched. Both production application pods were Ready with zero restarts and actual imageIDs equal to the previously verified candidate backend/frontend digests. The startup probe was retained during recovery.
The authenticated normal website account API again returned all three affected accounts unblocked with capacity_next_probe_at=null. Aggregate capacity: five online slots, one busy and four available. The obsolete November paid-credit reset no longer blocks available included subscription capacity. The original capacity fix, normal preserved-source TEST delivery and engine-owned production recovery are now verified. Included capacity, protected manual reserves and paid budget authority remain separate; no new paid calls or permission/flag changes were made by this repair.
Clean task-owned source worktrees are being removed after verifying every HEAD is integrated into development; published Git history, branches, PRs, interrupted-attempt receipts and bounded restricted audit evidence remain preserved. No unrelated working copy is changed. Separate monitor status-mapping and receipt/ancestor atomicity findings remain recorded above; they are not claimed fixed. The 30-second authorization timeout was not changed: the single governed recovery succeeded at authorization, and the actual rollout blocker was startup/liveness interaction.