🔑 feat: Allow Installation-Scoped GitHub Tokens for Trusted Workers - #263
Conversation
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e78dfe33b5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ? cachedInstallation && | ||
| now.getTime() - (this.installationIdCachedAt.get(repository!) ?? 0) < GITHUB_INSTALLATION_CACHE_MS | ||
| ? cachedInstallation | ||
| : await this.resolveInstallationId(repository ?? '', await this.appJwt(now), signal) |
There was a problem hiding this comment.
Bound the initial installation lookup with the shared timeout
When installation scope has a cold or two-minute-old repository mapping, this lookup runs before the shared request is created and receives only the caller's signal. Unlike the repository-scoped path below, it therefore bypasses GITHUB_SHARED_REQUEST_TIMEOUT_MS: a direct getCredential call without a signal can hang indefinitely, while worker calls can consume the remainder of the assignment deadline if GitHub accepts the connection but never responds. Perform this lookup with a bounded/shared signal as well.
Useful? React with 👍 / 👎.
|
@codex review the latest head |
|
Codex Review: Didn't find any major issues. 🚀 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Summary
Commands on a trusted VM currently receive a token restricted to the repository selected when the command starts. Starting in one checkout and using
cdorgit -Cto push another repository in the same GitHub organization therefore fails with 403 even when the App installation includes both repositories.I added an opt-in installation token scope. The worker still resolves the App installation from the admitted checkout, but asks GitHub for a token covering the repositories that installation permits. GitHub's repository selection and App permissions remain the authority. The default remains a token restricted to one repository.
--github-token-scope installationandLIBRECHAT_CODE_GITHUB_TOKEN_SCOPE=installation, restricted to trusted VM App workers without a fixed installation ID.Flow
Change Type
Testing
From
packages/code, I rannpm run buildandnode --test dist/github.test.js dist/cli.test.js: 51 passed. The new tests cover same-installation token sharing, separate organization installations, permission refresh, repository transfer, and CLI admission.Test Configuration
Node 24.16.0 on macOS. No live worker was restarted for this PR.
Checklist