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
stderrExcerpt capped at a few hundred bytes, or
- a parsed
reason enum 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.
Problem
executeGitinapps/server/src/vcs/GitVcsDriverCore.tsrecords onlystderrLengthon a failed git command and setsdetailto a static fallback string (fallbackErrorDetail ?? "Git command exited with a non-zero status."). The actual stderr text is dropped, so every downstream consumer ofGitCommandErrorsees an opaque message with no way to recover the cause.Concrete example
While testing the worktree MCP tools (#3754),
git worktree addfailed because the requested branch already existed and was checked out in another worktree. Git's stderr said exactly that. What surfaced instead was: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:stderrExcerptcapped at a few hundred bytes, orreasonenum 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.