[Bug]: Baseline checkpoint capture blocks the provider turn, so every turn in a slow workspace waits 30 seconds #28996

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

Summary

RunExecutionService.startRootRun waits for the baseline checkpoint before it starts the provider turn. In a workspace where git add -A can't finish in 30 seconds, every turn sits idle for about 31 seconds before the provider receives the prompt, then starts anyway without a baseline.

This is related to two open issues, but neither tracks this behavior:

• Explicit steer is refused with "No running provider turn found" during run startup/completion gaps #23271 / fix(server): queue explicit steer between provider turns #23559 / fix(server,web,mobile): steers sent before a turn starts join it once it does #25749: the steer refusal. Those fixes stop the error, but the turn still waits about 31 seconds.
• [Bug]: Checkpoint capture hits the 30 s git timeout in large workspaces and never converges; every killed attempt leaves a tmp_objdir-bulk-fsync-* directory behind #26227: why capture times out and leaks tmp_objdir-* directories. A faster capture shrinks the wait, but any capture that fails still costs the full timeout up front.

Steps to reproduce

1. Open a workspace with enough untracked data that git add -A takes over 30 seconds. Mine has 8,772 untracked files in a 1.4 GB tree.
2. Send a message on a Codex thread.
3. The UI shows the run as working immediately, but the provider log has no turn/start for about 31 seconds.
4. Send a follow-up with the default Steer behavior during that wait. It's refused with No running provider turn found for active run <runId>. and stays in the composer.

Expected behavior

A slow or failing baseline capture doesn't delay the provider turn. The capture could run alongside the turn, have a much shorter budget before the turn starts, or back off after repeated timeouts in the same workspace.

Actual behavior

The prompt doesn't reach the provider until capture times out. The result is thrown away (orchestration V2 checkpoint baseline capture failed; starting provider without a baseline), so the wait gains nothing, and the UI shows it as the agent working.

Times from one thread, relative to each run's startedAt:

The startRootRun trace for run B shows where the time went (durations rounded):

31429 ms  RunExecutionService.startRootRun                        Success
31062 ms    GitVcsDriver.checkpoints.captureCheckpoint            Failure
30509 ms      VcsProcess.run                                      Failure
30002 ms        processRunner.runProcessCore                      Interrupted
  153 ms    CodexAdapterV2.startNativeTurn                        Success

VcsProcessTimeoutError: VCS process timed out in GitVcsDriver.checkpoints.captureCheckpoint: git (<workspace>) after 30000ms

Across the six rotated server traces I checked, covering about two hours, 28 of 30 captures failed, and all 28 failures were in this workspace.

The same await is still on main at e6e2ab05c, in apps/server/src/orchestration-v2/RunExecutionService.ts:929. I confirmed the timing on 0.1.6 and read the code on main, but I didn't run main.

Impact

Major degradation or frequent failure

Version or commit

0.1.6 desktop (reproduced). The await is still present on main at e6e2ab05c.

Environment

Windows 11 Pro, git 2.56.0.windows.2, Codex provider (gpt-6.1-sol).

Logs or stack traces

This Windows workspace also leaks as #26227 describes: 30 tmp_objdir-bulk-fsync-* directories holding 89,696 files and 2.1 GiB in .git/objects.

Workaround

Add large untracked folders to .gitignore or .git/info/exclude. I haven't confirmed that this brings capture under 30 seconds in this workspace.