Repository navigation
Git command errors discard stderr, making failures opaque to callers #4380
Description
Problem
executeGit in apps/server/src/vcs/GitVcsDriverCore.ts records only stderrLength on a failed git command and sets detail to a static fallback string (fallbackErrorDetail ?? "Git command exited with a non-zero status."). The actual stderr text is dropped, so every downstream consumer of GitCommandError sees an opaque message with no way to recover the cause.
Concrete example
While testing the worktree MCP tools (#3754), git worktree add failed because the requested branch already existed and was checked out in another worktree. Git's stderr said exactly that. What surfaced instead was:
Git command failed in GitVcsDriver.createWorktree (<cwd>): git worktree add failed
Diagnosing it required manually re-running the git command outside the app. Any git precondition failure (branch exists, path exists, stale worktree metadata, permissions, missing ref) collapses into the same string.
Suggested fix
Keep the structural fields as they are, but carry a bounded, useful signal on GitCommandError, for example:
- a
stderrExcerptcapped at a few hundred bytes, or - a parsed
reasonenum for common git failures (ref exists, path exists, not a repository, permission denied), with the excerpt as fallback.
If dropping stderr is deliberate (telemetry hygiene, path leakage), a capped and sanitized excerpt on the in-process error object only, excluded from telemetry serialization, would still fix the developer experience without changing what leaves the machine.
Activity
Carry a redacted stderr excerpt on git command failures
michidk commentedon Aug 26, 2026
Another concrete reproduction is
GitVcsDriver.fetchRemotefailing because Git refuses to overwrite a moved tag.The UI only shows:
Re-running the same fetch in the affected checkout reveals the actionable stderr that the toast omits:
This repository has global
fetch.prune=trueandfetch.pruneTags=true; its localproductiontag differs from the remote tag.git -c fetch.pruneTags=false fetch --dry-run originsucceeds.PR #7619 fixes this particular fetch failure by passing
--no-tags --no-prune-tags, but the opaque-error issue remains relevant for otherfetchRemotefailures: #7619It would be useful for the toast (or an expandable details area) to expose a bounded/sanitized stderr excerpt, so users can distinguish tag conflicts, authentication failures, missing remotes, and network errors without manually reproducing T3 Code’s Git command.
rzxx commentedon Oct 31, 2026
Confirmed on T3 Code Desktop/server
0.1.6-nightly.20261031.3977, Windows x64, Git2.56.0.windows.4.Commit & Push failed with:
Running the repository’s unchanged pre-commit hook independently revealed the cause: Gitleaks rejected a numeric test fixture under a custom privacy rule. The hook correctly blocked the commit, but the error message didn’t identify the hook or explain the rejection.
The current source still propagates the generic failure. #22939 fixes hook completion tracking and is included in this build; the actionable rejection message proposed in #7706 was not merged.
Could this case show a safe message such as “The pre-commit hook rejected the commit (exit code 1). Run the hook locally for details”? That would help without exposing potentially sensitive hook output.
Investigated with Codex (
gpt-6.1-sol) via T3 triage.