Windows: large Codex transcript saturates CPU during post-commit (12m43s), interrupted capture leaves checkpoint trailer without remote data

Start by locating the native Git post-commit hook and the transcript condensation, redaction, and checkpoint storage steps named in the report; inspect the performance logging for those steps. Reproduce with a large transcript on Windows only in a safe environment, since upstream reproduction is unconfirmed. Done means post-commit processing no longer causes excessive CPU and latency, and an interrupted run can be safely resumed without leaving a missing checkpoint unnoticed.

What happened?

On Windows, native post-commit checkpoint processing for a long-lived Codex session saturated the workstation CPU and made the machine extremely slow/unresponsive. The operator explicitly reported 100% CPU and severe desktop freezes.

The native transcript was approximately 5.1 GB (5,098,597,148 bytes at observation). A successful manual recovery took 763,636 ms (12m43.636s) and condensed 185,129 transcript lines. Another real commit started the same heavy post-commit processing again; we stopped that owned process after the operator reported the machine becoming unusable.

This is a report of the observed local build below, not a claim of reproduction with an unmodified upstream release. We did not repeat the resource-intensive reproduction on the affected workstation.

Entire CLI version

Entire CLI 0.12.2-lcv.windows-console.1
Go version: go1.27.3
OS/Arch: windows/amd64

This is a locally suffixed Windows console build based on 0.12.2. The installed package manifest points to the official v0.12.2 Windows distribution, but the running executable identifies itself as above. Please keep that qualification when triaging; upstream reproduction has not been established.

Environment

• Windows amd64; PowerShell; Codex local workstation session.
• Existing Git worktree, normal signed local commits and native Entire Git hooks.
• commit_linking: "always".
• Checkpoint backend: git-refs.
• PII redaction enabled (email and phone), OPF disabled.
• The long-lived Codex session began in a workspace parent directory and was subsequently recognized as active in a repository worktree.
• No --no-verify, manual checkpoint trailer, signing bypass, transcript truncation or redaction disablement.

Observed sequence

1. Make a real repository change and run a normal signed git commit.
2. The prepare-commit-msg hook writes a genuine Entire-Checkpoint trailer.
3. The synchronous post-commit processing does not finish within the terminal runner's initial 150-second deadline. The runner, not Entire, times out.
4. The code commit already exists. A normal code push succeeds, but the referenced new checkpoint is absent from remote refs; entire checkpoint explain <id> --repo gh/<owner>/<repo> --json reports checkpoint not found.
5. Run the official entire hooks git post-commit recovery with a larger outer deadline.
6. Recovery eventually creates the local checkpoint ref after 763.636 seconds. During this recovery the process had high CPU utilization and no child process doing the work.
7. A subsequent real commit invokes the native hook again and produces the same workstation resource pressure. The operator reports 100% CPU, extreme slowness and freezes. We interrupt only this execution's post-commit process and its associated shim; the signed code commit remains intact.

There is also a repository-boundary concern: the newly materialized checkpoint's first transcript record predates worktree activation and points to the workspace parent, rather than starting at repository activation. We have withheld publication of that historical checkpoint pending clarification; the transcript spans work outside this repository. We are not attaching or uploading that content.

Performance evidence

Values below are copied from the native JSON performance log; session IDs, local paths and checkpoint identifiers are intentionally omitted:

{
  "op": "post-commit",
  "duration_ms": 763636,
  "slow": true,
  "steps.open_repository_and_head_ms": 83,
  "steps.find_sessions_for_worktree_ms": 31,
  "steps.resolve_commit_trees_ms": 31,
  "steps.process_sessions_ms": 763464,
  "steps.process_sessions.0_ms": 763464,
  "steps.process_sessions.0.check_session_content_ms": 0,
  "steps.process_sessions.0.transition_and_condense_ms": 763205,
  "steps.process_sessions.0.extract_session_data_ms": 15674,
  "steps.process_sessions.0.redact_transcript_ms": 443890,
  "steps.process_sessions.0.redact_transcript~1_ms": 262,
  "steps.process_sessions.0.write_committed_v1_ms": 226456,
  "steps.process_sessions.0.write_committed_v1.chunk_transcript_ms": 38060,
  "steps.process_sessions.0.write_committed_v1.chunk_transcript.write_transcript_blobs_ms": 45286,
  "steps.process_sessions.0.write_committed_v1.chunk_transcript.write_transcript_blobs.write_transcript_content_hash_ms": 6120,
  "steps.process_sessions.0.write_committed_v1.write_compact_transcript_ms": 40837,
  "steps.process_sessions.0.carry_forward_files_ms": 82,
  "hook_type": "git"
}

The native condensation event reported checkpoints_condensed: 1 and transcript_lines: 185129. Other lifecycle events recorded 218,431 ms for post-tool-use and 330,882 ms for subagent-stop while this operation was in progress. Those durations are observations, not proof of an independent root cause.

Expected behavior / requested fix

• Bound CPU/concurrency or otherwise avoid making the workstation unusable during checkpoint redaction/storage.
• Avoid repeatedly processing the whole historical transcript when only a small new code change is committed, if feasible.
• Provide visible progress and safe cancellation/resumption for long condensation operations.
• Clearly surface a commit trailer whose checkpoint has not yet materialized, instead of allowing an ordinary push to look complete while the checkpoint is missing.
• Warn about or explicitly scope adoption of a pre-existing multi-repository Codex session into one repository; provide a supported repository/session boundary for capture.
• Please advise the supported recovery procedure for interrupted condensation without bypassing hooks/signing, weakening redaction, inventing checkpoint trailers, or importing unrelated history.

Related reports: #591 (older orphaned-session commit slowness) and #2663 (legacy shadow-branch transcript duplication/storage). This observation uses the current git-refs checkpoint backend and records a synchronous post-commit CPU/latency and interrupted-publication failure. I could not find an open report covering this exact sequence.

No transcript, credentials, customer data, full logs or diagnostic bundle are attached.