[Bug]: PullRequestSyncReactor's gh calls fail with an opaque error — VcsProcessExitError discards stderr, so the real cause can't be diagnosed

Edit: the original diagnosis below ("not a git repository" because cwd defaults to $HOME) is retracted — see the correction comment below. cwd is confirmed (by reading the actual source) to be the real project.workspaceRoot, not a wrong default, and gh pr view --repo <owner>/<repo> (what T3 actually runs) does not require cwd to be a git repo at all. The real cause of the 25 failed gh calls in the evidence below is unknown, because VcsProcessExitError discards the actual stderr text (see the comment for detail — same defect class as #4380, different type/file). Leaving the raw evidence (timing, cwd, frequency) as filed since it's still accurate; only the diagnosis is wrong.

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

This is a background-reactor bug, not directly user-triggered, so there isn't a UI click-path repro. It shows up passively:

1. Run T3 Code server/desktop with at least one project open that has a GitHub remote and an active/linked thread (PR-related state).
2. Leave the app running normally (this is not idle-only — it also happened while a thread was actively being worked in the same window).
3. Tail apps/server trace logs (~/.t3/userdata/logs/server.trace.ndjson*) and filter for "name":"PullRequestSyncReactor.syncGroup" (or PullRequestReadCache.get, GitHubCli.executeRaw) with "_tag":"Failure".
4. Every occurrence has gh (/Users/<user>) in the error chain. That cwd is the real project.workspaceRoot (confirmed by reading PullRequestService.summaryUncached → requireProject → getChangeRequestSummary), not a bug in cwd resolution — see the edit note above.

VcsProcessExitError only records stderrLength/stderrTruncated, not the stderr text, so the actual reason gh exited 1 is not recoverable from this trace. It was classified as the generic "command-failed" bucket by classifyNonZeroExit (not auth, not rate-limited, not not-found), which only narrows it down, doesn't identify it.

Expected behavior

VcsProcessExitError (and its gh/glab/az callers through GitHubCli/VcsProcess) should carry enough of the real stderr to diagnose a command-failed exit, instead of only stderrLength. See #4380 for the same defect in GitCommandError (plain git commands) — this is asking for the same fix applied to VcsProcessExitError.

Actual behavior

25 distinct gh invocations failed with exit 1 over a 3.5h window (below), roughly 60s apart, matching the reactor cadence already described in #11220. The failure is silent from the user's perspective — nothing surfaces in the UI, only the trace logs — so PR data for the affected thread(s) may simply never populate, with no way (yet) to tell why.

Observed over a 3.5h window: 25 distinct failed gh invocations (PullRequestSyncReactor.syncGroup → PullRequestService.persistedRead → PullRequestReadCache.get → GitHubCli.executeRaw), each one logged at up to 15+ nested effect-span layers (382 raw "_tag":"Failure" log lines total for these 25 logical failures), spaced roughly 60s apart, all with gh (/Users/ryan) in the cause chain.

Impact

Major degradation or frequent failure

Version or commit

T3 Code Nightly 0.0.43-nightly.20260917.1837

Environment

macOS 27.0 (build 26A428), Bun 1.4.2, Node v26.8.2, gh 2.83.1, GitHub provider = github.com with personal OAuth token (not a GitHub App installation token — rules out #11247).

Logs or stack traces

PullRequestOperationError: Pull request operation summary failed: GitHub CLI command failed.
    at PullRequestReadCache.get (Nightly)
    at PullRequestService.persistedRead (Nightly)
    at PullRequestSyncReactor.syncGroup (Nightly)
    at PullRequestSyncReactor.sweep (Nightly) {
  [cause]: PullRequestProviderError: github failed in getChangeRequestSummary: GitHub CLI command failed. {
    [cause]: GitHubCliCommandError: GitHub CLI failed in execute: GitHub CLI command failed.
        at fromVcsError (bin.mjs:86949:9) {
      [cause]: VcsProcessExitError: VCS process failed in GitHubCli.execute: gh (/Users/ryan) exited with 1 - Process exited with a non-zero status.
          at VcsProcessExitError.fromProcessExit (bin.mjs:31123:10)
    }
  }
}

Note: gh pr view --repo <owner>/<repo> --json ... (what T3 actually runs here) does not require cwd to be a git repo — verified directly (cd /Users/ryan && gh pr view 11225 --repo pingdotgg/t3code --json number,title succeeds, exit 0). An earlier manual repro using gh pr list (no --repo) is not representative of this call shape and has been removed.

Workaround

None found — the real cause is unknown pending a stderr excerpt on VcsProcessExitError.

Start by tracing VcsProcessExitError.fromProcessExit through GitHubCli.execute and VcsProcess, then compare the requested behavior with issue #4380's GitCommandError fix. Done means command-failed errors retain enough stderr for the existing trace logs to identify why gh, glab, or az exited nonzero, without changing the reported command context.