[Bug]: Go back intermittently fails with an opaque Git exit 128 during checkpoint restore

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Intermittent behavior under normal use

1. Open a local Git repository in T3 Code.
2. Use a Codex thread for several turns so that multiple checkpoints exist.
3. Wait for the thread to become idle.
4. Use Go back on an earlier turn.
5. The restore intermittently fails with Git exit 128.

I observed five Git restore failures across two worktrees over two days. Four other restore attempts succeeded. At least one checkpoint target failed and then succeeded several minutes later, so the target ref itself was not permanently invalid.

Deterministic way to exercise the failure path

This reliably reproduces the same user-visible failure path, but I do not know whether it is the cause of the naturally occurring failures:

1. In a repository with a restorable T3 checkpoint, create an index lock:

   lock_path=$(git rev-parse --git-path index.lock)
   touch "$lock_path"
   

2. Click Go back in T3 Code.

3. Remove the test lock immediately afterward:

   rm "$lock_path"
   

T3 reports the generic exit-128 error below. Git itself reports an actionable “Unable to create .../index.lock: File exists” error for the restore command in this condition.

Expected behavior

Go back should restore a valid checkpoint during normal idle use. If Git cannot restore it because of transient repository state, the error should identify the actionable reason rather than only reporting exit 128.

Actual behavior

Go back sometimes fails immediately with:

VCS process failed in GitVcsDriver.checkpoints.restoreCheckpoint: git (/Users/midm/Dev/one-click-os) exited with 128 - Process exited with a non-zero status.

The underlying Git stderr is not included, so it is not possible to tell from the report whether git restore, git clean, or git reset failed or why.

The failure happens before provider conversation rollback, so the thread and filesystem appear to remain at their pre-request state.

Impact

Major degradation or frequent failure

Version or commit

T3 Code Alpha 0.0.31

Environment

macOS 26.4.1 (25E253), Apple Git 2.50.1, T3 Code desktop app, Codex app-server provider. Repository is a large monorepo with multiple linked worktrees.

Logs or stack traces

VCS process failed in GitVcsDriver.checkpoints.restoreCheckpoint: git (/Users/midm/Dev/one-click-os) exited with 128 - Process exited with a non-zero status.

Investigation notes

• The checkpoint refs resolve to valid commits.

• Git repository connectivity checks did not report corruption.

• The exact restore sequence from T3 0.0.31 succeeds in a full APFS copy-on-write clone of the repository, including the real index and ignored build/vendor trees:

  git restore --source <checkpoint-commit> --worktree --staged -- .
  git clean -fd -- .
  git reset --quiet -- .
  

• No stale index.lock remained when checked immediately after a naturally occurring failure.

• Holding index.lock reproduces an immediate Git exit 128 deterministically.

• T3 also runs background Git status/checkpoint operations, so transient index contention seems plausible. However, because stderr from a naturally occurring failure was not retained, this is only a hypothesis and may not be the root cause.

• Other transient causes have not been ruled out.

Workaround

Retrying after other Git/agent activity has settled sometimes succeeds, but it is not reliable.

Start in apps/server at GitVcsDriver.checkpoints.restoreCheckpoint and trace the restore command sequence documented in the report. Reproduce the index.lock case, then inspect how Git stderr is handled for restore, clean, and reset failures. Done means Go back restores valid checkpoints and reports the actionable Git reason when restoration fails.