feat: private remote git auth#232
Conversation
- Use Number.parseInt/Number.isNaN instead of global functions - Use optional chains for index access in loader - Use bracket notation for process.env (noPropertyAccessFromIndexSignature) - Replace forEach with for...of in pr-workflow - Add JSDoc for githubToken in auth-options
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| lower.includes('access denied') || | ||
| lower.includes('403') | ||
| ); | ||
| } |
There was a problem hiding this comment.
Overly broad '403' match in auth failure detection
Medium Severity
The isGitAuthFailure function includes lower.includes('403') which is overly broad. A GitHub 403 can indicate rate limiting rather than an authentication or authorization problem. When a token is provided but the failure is actually rate limiting, the error message will misleadingly say "Failed to authenticate when cloning" and tell the user to check their token's read access — sending them on a wild goose chase instead of surfacing the real issue.
| execGit(['fetch', '--depth=1', '--', repoUrl], { cwd: remotePath, env: gitAuthEnv }); | ||
| } else { | ||
| execGit(['fetch', '--depth=1', '--', repoUrl], { cwd: remotePath }); | ||
| } |
There was a problem hiding this comment.
Redundant conditional branches in update fetch path
Low Severity
The if (useGitHubAuth) ... else ... branches in the update path are functionally identical. gitAuthEnv is already undefined when !useGitHubAuth, so passing { env: gitAuthEnv } in both cases produces the same result. This could be collapsed into a single execGit call with { cwd: remotePath, env: gitAuthEnv }.


Please see specs/private-remote-auth-rollout.md