[Bug]: Individual git actions after error #1368

Activity

1. lpalmeida-klab

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Mar 24, 2026
2. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Mar 25, 2026
3. juliusmarminge commented on Mar 25, 2026

   

   juliusmarminge

   on Mar 25, 2026

   Member

   More actions

   We should check that gh is installed and authed before showing PR actions

   👍React with 👍1Reacted by Luis Almeida
4. Parth-Jadhav-2004 commented on Apr 28, 2026

   

   Parth-Jadhav-2004

   on Apr 28, 2026

   More actions

   @juliusmarminge Can I try to solve this issue ? or is it fixed already ??
5. baichen99 commented on Jul 27, 2026

   

   baichen99

   on Jul 27, 2026

   More actions

   I'll take a shot at this.

   Root cause: VcsStatusResult (the git status payload the web UI uses to decide whether "Create PR" is enabled) has no field describing GitHub CLI auth state, so buildMenuItems/resolveQuickAction in GitActionsControl.logic.ts can never gate the PR actions on whether gh is installed/authenticated. The button either looks clickable and then fails server-side, or (depending on git status) stays in a state that doesn't explain why.

   The auth probe already exists and is used elsewhere (sourceControlEnvironment.discovery, consumed today only by the Publish-repository dialog's getPublishProviderReadiness). Plan is to surface that same readiness into the main Commit/Push/Create-PR action group, with a specific disabled-reason hint when GitHub CLI is missing/unauthenticated.

   Will keep the diff small and scoped to this, per CONTRIBUTING.md.
6. t3dotgg commented on Aug 27, 2026

   

   t3dotgg

   on Aug 27, 2026

   Member

   More actions

   Thanks for the detailed report. We believe this is fixed by PR #2462.

   The original disabled-retry defect has a plausible landed fix that predates the recent audit window. After commit and push succeed but PR creation fails, aheadCount is zero because the branch matches its remote. The old menu required aheadCount > 0, so logging in could never re-enable Create PR. The GitLab integration changed both menu and quick action to use aheadOfDefaultCount, keeping Create PR enabled for a pushed feature branch. The later request to preflight CLI authentication is separate and remains in the open auth-readiness proposal.

   I'm closing this as fixed as part of an automated pass on all open issues. If this still happens in a current build that includes PR #2462, please reply with the T3 Code version and fresh logs or reproduction details, and we can reopen it.
7. t3dotgg

   closed this as completedon Aug 27, 2026