fix(auth): scope MCP repository access - #484
Merged
JSONbored merged 1 commit intoJun 10, 2026
Merged
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
gittensory-ui | 6ccf6a9 | Commit Preview URL Branch Preview URL |
Jun 10 2026, 06:04 AM |
|
Note Gittensory Gate skippedPR closed before full evaluation. No late first comment was created.
Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers. |
This was referenced Jun 9, 2026
This was referenced Jun 10, 2026
Merged
JSONbored
force-pushed
the
codex/propose-fix-for-github-session-vulnerability
branch
from
June 10, 2026 05:56
07463be to
9ef69be
Compare
JSONbored
force-pushed
the
codex/propose-fix-for-github-session-vulnerability
branch
from
June 10, 2026 06:02
9ef69be to
6ccf6a9
Compare
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
1 similar comment
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Closed
12 tasks
This was referenced Jul 2, 2026
This was referenced Jul 31, 2026
JSONbored
added a commit
that referenced
this pull request
Jul 31, 2026
…ge (#10266) `escalate-workflow-outage.ts` counted every non-success at the head of a workflow's run history, so a maintainer retrying a publish by hand escalated as a standing outage. That is what #10171 was: six consecutive publish-miner.yml failures, every one a hand `gh workflow run` against main failing ETARGET on a @loopover/contract version that was not published yet. The next run after contract landed succeeded with no code change. Filtering on the run's `event` / `triggering_actor` / `head_branch` cannot work here, and the header records why so it is not tried again. The reconcile path in mcp-release-please.yml dispatches a bare `gh workflow run "$workflow"` under a PAT, so its runs land as `workflow_dispatch` / `main` / the PAT owner -- the identical triple a laptop produces. Verified against live history: publish-miner run #484, which the reconcile job's own log shows it dispatched, is indistinguishable on every one of those fields from the six manual #10171 failures, and `GET /actions/runs/:id` exposes no `inputs` key either. So provenance is stamped at dispatch instead. `run-name:` is rendered into `display_title`, which the runs API does return -- the same mechanism visual-capture-fallback.yml already uses to correlate a dispatch to its PR. The five publish workflows take a `dispatched_by_automation` input and stamp a marker into their run name; both dispatch sites pass it; the streak counts only runs carrying it. Manual runs are excluded rather than merely not resetting the streak: a run nobody automated is not evidence about the automated path in either direction. Non-dispatch triggers still count exactly as before, so selfhost.yml -- the other caller, and push-triggered -- is unchanged. Runs already in the history carry no stamp and so read as unattributable. The publish escalation therefore stays quiet until three stamped automated failures accumulate; under-alerting briefly is the fail-safe direction and beats re-creating the false alarm this removes. check-dispatch-provenance-stamped.ts asserts the lockstep, since both sides of the marker fail silently: a drifted `run-name:` leaves the escalation reading every automated run as manual, still green and still "wired" while covering nothing. It also rejects an unconditional marker, which would stamp a human's dispatch as automated and restore the original false alarm. Closes #10234
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Description
requireRepoAccessandloadSessionAccessScopeonGittensoryMcpand usingloadControlPanelAccessScopeto compute a session's scoped repos and account logins, with a short-lived per-instance cache. (src/mcp/server.ts).requireRepoAccessfor MCP repo-scoped tools before loading cached private repo data, includinggetRepoContext,getBurdenForecast,getIssueQuality,getRepoOutcomePatterns,explainRepoDecision,preflightPr,preflightLocalDiff,previewScore,explainReviewRisk,analyzeLocalBranch, andgetBountyAdvisory(all insrc/mcp/server.ts).repositoryFullNamesor account-owned repos in the access scope; unauthorized sessions now fail early with a forbidden error.test/integration/api.test.ts.Testing
NO_COLOR=1 npx vitest run --config vitest.config.ts test/integration/api.test.ts -t "blocks command previews for sibling repos" --reporter verbose, and the test passed (1 test run, others skipped as expected).npm run typecheck(tsc --noEmit) which succeeded with no errors.Codex Task