Skip to content

Git command errors discard stderr, making failures opaque to callers #4380

Description

@nsxdavid

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.

Activity

  1. added a commit that references this issue on Aug 15, 2026
    6bf9ee8
  2. michidk commented on Aug 26, 2026

    @michidk

    Another concrete reproduction is GitVcsDriver.fetchRemote failing because Git refuses to overwrite a moved tag.

    The UI only shows:

    Git command failed in GitVcsDriver.fetchRemote (/Users/michi/dev/web-platform-3): git fetch origin failed
    

    Re-running the same fetch in the affected checkout reveals the actionable stderr that the toast omits:

    From github.com:spanflug/web-platform
     ! [rejected] production -> production  (would clobber existing tag)
    

    This repository has global fetch.prune=true and fetch.pruneTags=true; its local production tag differs from the remote tag. git -c fetch.pruneTags=false fetch --dry-run origin succeeds.

    PR #7619 fixes this particular fetch failure by passing --no-tags --no-prune-tags, but the opaque-error issue remains relevant for other fetchRemote failures: #7619

    It 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions