GeezerVison is showing github.com — Make ci-watch.sh work in GraphQL-less cloud sessions by mikolalysenko · Pull Request #1620 · SocketDev/socket-patch
Conversation
Problem
AGENTS.md tells every agent to wait on CI with scripts/ci-watch.sh, but in Claude Code cloud sessions (where every routine in this fleet runs) GraphQL now returns HTTP 403: GitHub GraphQL is not available from Claude Code sessions. The script calls gh repo view (GraphQL) before anything else, so it exits 2 at startup there with no event line; gh pr view, gh pr checks and the gh api graphql poll are all GraphQL too. Verified in this session on 2026-10-17: gh repo view, gh pr checks 1590 and the queue GraphQL query all 403.
Agents then fall back to ad-hoc polling, which is exactly what AGENTS.md asks them not to do (and costs more of the shared API budget).
Root cause
The watcher is GraphQL-only; cloud sessions only allow REST.
Fix
- Repo comes from
GH_REPO or the origin URL (falls back to gh repo view).
- Default PR:
gh pr view, else GET pulls?head=<owner>:<branch>.
- On the first
GraphQL is not available 403 the script switches to REST for good. Each poll reads pulls/N (state, merged, head, base), the head's check runs (filter=latest default) and commit statuses; the base branch's required checks (rules/branches/<base>, read once: ci-ok, clippy) must all have reported before it calls DONE, standing in for the rollup that counts expected checks.
--merge over REST: REST has no merge-queue entry, so the queue lines follow the PR's unfinished merge_group runs (gh-readonly-queue/<base>/pr-N-*); left the queue needs two misses in a row so a rebuild isn't read as a dequeue. Position is shown as building.
- After a merge group's runs all pass, the watcher waits for MERGED (up to 10 min) instead of counting a dequeue; while the required-check list can't be read the rollup stays pending (Bugbot findings, fixed in b53f491).
- The GraphQL path is unchanged where GraphQL works (local terminals).
Budget: REST mode is 3 requests per poll (4 with --merge), at the default 120 s interval ~90-120/h per watcher.
Proof
Live, in this cloud session:
$ scripts/ci-watch.sh 1590 --interval 5
warn: GraphQL unavailable here; polling over REST
start: #1590 c38b16316, 55 pass 0 fail 0 pending
DONE checks pass (55 checks)
$ scripts/ci-watch.sh 1586 --merge --interval 5
warn: GraphQL unavailable here; polling over REST
start: #1586 bca69ddeb, 86 pass 0 fail 0 pending
DONE merged
Before this change both exit 2 immediately.
With a stubbed gh (pending→failure, required ci-ok arriving late, queue enter→merge, queue enter→dequeue after two misses):
start: #7 abc123def, 2 pass 0 fail 1 pending
fail: test
fail: ci-ok
DONE checks fail (2 of 4 failed) # waited for ci-ok before DONE
---
queue: entered at building
DONE merged
---
queue: entered at building
queue: left the queue
DONE dequeued
bash -n clean; shellcheck isn't installed in this environment.
Where tests run
No tests or jobs change; this is an agent-side script only.
https://claude.ai/code/session_01AqtsyAYsehu1NAZhKbg3o5
Generated by Claude Code
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Claude Code cloud sessions get a 403 for every GraphQL call, and gh pr
view, gh pr checks and gh repo view all use GraphQL, so the CI watcher
AGENTS.md tells agents to run exited at startup there with no output.
Read the repo from GH_REPO or the origin URL, find the branch's PR over
REST when gh pr view fails, and on the first "GraphQL is not available"
403 switch to REST polling: the PR, its check runs and commit statuses,
with the base branch's required checks standing in for the rollup. With
--merge, queue lines follow the PR's merge_group runs. The GraphQL path
is unchanged where GraphQL works.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01AqtsyAYsehu1NAZhKbg3o5
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
cursor
Bot
left a comment
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stale Bugbot comment from a previous run.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Over REST, a merge group whose runs all passed leaves the PR open for a
moment before it merges; wait for the merge (up to 10 minutes) instead
of counting those polls as misses. And keep the rollup pending while the
base branch's required checks can't be read, so an unreadable rule set
can't let DONE through before ci-ok reports.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01AqtsyAYsehu1NAZhKbg3o5
cursor[bot] reacted with thumbs up emoji
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit b53f491. Configure here.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
Ready for review at b53f491.
- CI: 54/54 green (35 success, 19 skipped); mergeable, no conflicts.
- Bugbot: clean on
b53f491. Both earlier findings (from 9f1f2de) were fixed and their threads are resolved.
- Reviewer focus:
scripts/ci-watch.sh only. Check the REST fallback paths that replace the GraphQL status and merge-queue queries.
Slack announcement not sent in this run (no Slack send tool was available).
Generated by Claude Code
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
|
Dequeued for e2e (ubuntu-latest, e2e_vex_build, pipenv:: --ignored, 2026.8.0). This failure isn't from this PR, which only changes scripts/ci-watch.sh. The same failure happened twice in the queue, the second time on a merge group built directly on main 14eee88.
Cause: uv 0.13.2 (released 2026-10-19 20:59 UTC) started rejecting Pipenv 2026.8.0's environments = [] pylock (error: The target environment is not supported by the lockfile). The Pipenv/pip legs get uv from an unpinned astral-sh/setup-uv. I reproduced it locally: uv 0.13.1 gets past the environment check, while 0.13.2, 0.13.3 and 0.13.4 all refuse.
The fix is #1639, which pins that uv to 0.13.1. It is green (55/55) and is waiting on a human approval. This PR can be re-queued once #1639 merges. I'm not porting the pin here: that would duplicate #1639 and dismiss this PR's approval.
Generated by Claude Code
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
[final reviewer] Re-added to the merge queue (squash, auto-merge) at b53f491fa, which is the commit Wenxin Jiang (@Wenxin-Jiang) approved. The earlier eviction was the main-wide uv 0.13.2 Pipenv pylock break. main now pins setup-uv to 0.13.1 (#1605), and the same e2e … pipenv:: --ignored, 2026.8.0 leg is green on main a54753a. This is the one re-enqueue after that eviction.
Generated by Claude Code
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assigned
Labels
ci-janitor
Opened by the CI janitor routine (flakes, redundant tests, CI perf)
Ready for review
Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review
Milestone
No milestone
Development
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.
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.
|