/ultraplan cloud session: false-positive 'GitHub app must be installed' + plan committed locally but never pushed back (regression of #21377)

Title

/ultraplan cloud session: false-positive "GitHub app must be installed" + plan committed locally but never pushed back to remote (regression of #21377)

Environment

• Claude Code: 2.1.126 (Windows installer)
• OS: Windows 11 Pro 26200
• Shell: Git Bash (MSYS2)
• gh CLI: 2.89.0, authenticated to github.com over HTTPS, account jonboy648
• Repo: github.com/jonboy648/ai-anime (private, single-owner)
• Claude GitHub App: installed via https://github.com/apps/claude on the user account, with the repo selected (verified in github.com/settings/installations UI; cannot self-verify via REST API since repos/.../installation requires app JWT and user/installations requires OAuth token, not a PAT)
• Git remote: origin -> https://github.com/jonboy648/ai-anime.git (HTTPS, working — verified by hand-pushing a feature branch from a local terminal during the same hour the cloud session was failing)

Summary

Two distinct symptoms that I believe share a root cause, both in the /ultraplan cloud session flow:

Symptom A — install false-positive. /ultraplan repeatedly refuses to launch with the error "The Claude GitHub app must be installed on this repository first," despite the app being correctly installed and the repo being included in the selected-repository set. Hit ~8 times across one session. Eventually got past it after a manual /login rotation (token rotated, scopes unchanged: user:file_upload, user:inference, user:mcp_servers, user:profile, user:sessions:claude_code) — but no user-side action explains why it succeeded then versus the prior 8 attempts. Suggests a backend cache miss or stale install-state lookup.

Symptom B — committed locally inside sandbox, never pushed back. Once /ultraplan finally launched, it ran cleanly (claimed branch feat/mvp-stages-1-4-skeleton was created at commit 2fa468f with 11 tests passing). But:

• The branch was never pushed to origin. git fetch && git branch -r from my local repo showed no such ref.
• The session UI claimed success and offered to "open a PR," but the PR creation step also silently failed.
• When I asked the cloud session what happened, it said "no remote configured" — but origin was set, HTTPS, and worked when I pushed from my own terminal minutes later.

Why I think these share a root cause

Both look like the cloud session has a stale or wrong view of repository state at the moment it tries to act:

• A: stale view of "is the app installed for this repo right now."
• B: stale view of "does this repo have a remote, and does the session have credentials to push to it."

In both cases the local-side ground truth (GitHub UI for A, git remote -v + working hand-push for B) contradicts what the cloud session sees. So I suspect a single backend caching or session-state-snapshot bug rather than two separate bugs.

Reference to prior issue

Issue #21377 (closed for inactivity by github-actions[bot] on 2026-04-09, locked 2026-04-19) reported Symptom A. Last user comment on that issue ("Same problem here, need to fix asap") was from zazao on 2026-03-11. The bot's closing message asks people experiencing the same to file a new issue and reference the old one — that's what this is. The closure was inactivity-driven, not fix-driven, so there is no shipped fix to regress against; the bug appears to have just persisted.

Repro steps

1. Fresh repo: git init && gh repo create ai-anime --private --source=. --remote=origin --push
2. Install Claude GitHub App on the user account; select this repo.
3. Run /ultraplan from inside Claude Code with a planning prompt.
4. Observe Symptom A: "The Claude GitHub app must be installed on this repository first." Retry. Re-install. Toggle all-repos vs selected. Retry again.
5. Eventually succeed (no clear trigger — for me, a manual /login and one more retry).
6. Observe Symptom B: cloud session reports success, claims commit hash + branch name, but git fetch && git branch -r locally shows the branch is not on origin. PR creation silently fails too.

Severity / business impact

This turned a 30-minute planning pass into a 4-hour ordeal. The work the cloud session did (the planning + skeleton commit) was not lost only because I had it pasted in the chat scrollback and was able to reproduce it locally by hand. If the scrollback had been compacted or the user had closed the tab, all the work would have been gone. For users on Anthropic's paid Code plan, this is a "core feature looks like it works, then silently doesn't" failure mode — the worst kind, because there's no obvious error to report.

What would help

• A way to inspect the cloud session's view of (repo, install-state, remote, credentials) at the moment it makes its decision — even just a debug-mode dump in the session UI.
• A self-test step at the top of /ultraplan that does a git ls-remote and a no-op gh api repos/{owner}/{repo} from inside the sandbox, and surfaces the actual error if either fails, instead of falling through to the install-check.
• A retry-with-fresh-install-cache option in the UI when Symptom A fires.

Will provide on request

• Cloud session ID (session_01XmK1dJjUHXymNKY4Ykxs8c from one of the failed runs — happy to dig up the others).
• The full plan text the cloud session produced (was successfully pasted into PR #1 of jonboy648/ai-anime so it's recoverable).
• Timestamps of the ~8 install-error retries within an hour window on 2026-04-30.