[BUG] Claude Code web: PR activity subscriptions are silently scoped to the PR-creating account — cross-account subscribe fails with generic error

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On Claude Code on the web, subscribe_pr_activity fails with the generic error
"Could not subscribe to this PR." whenever the calling session belongs to a
different Claude account than the account whose session created the PR.

I have two Claude accounts (personal + work) authenticating as the same GitHub
user, with the Claude GitHub App installed and working on the repo. PRs were
created by sessions on my personal account. A work-account session cannot
subscribe to any of them, while my personal account subscribes/unsubscribes to
the same PRs without issue.

Controlled test from the work-account session against 10 open PRs in the same
repo: the 9 PRs created by personal-account sessions all fail; the 1 PR created
by a work-account session subscribes fine; a NONEXISTENT PR number (#99999)
also "subscribes" successfully, so no GitHub-side validation happens — the
check is purely against Anthropic's subscription store.

Also: unsubscribe_pr_activity from the ineligible account always returns
success (silent no-op), and after the personal-account session that created a
PR successfully unsubscribed, the work account STILL could not subscribe
minutes later — so eligibility follows the creating account, not the currently
active subscription.

Ruled out: GitHub App permissions (all other mcp__github__* calls work from
the same session), PR labels / steward watching label, auto-merge state
(toggled off and on — no change), owner-name casing, propagation delay,
stale subscription state in the calling session.

What Should Happen?

Any of:

1. Cross-account subscribe succeeds when both accounts authenticate as the

same GitHub user with access to the repo; or

1. A documented takeover/opt-out flow, like the PR Steward's watching-label

opt-out; or

1. At minimum an actionable error ("This PR is watched by a session on

another account") instead of "Could not subscribe to this PR."

Also expected: subscribing to a nonexistent PR should fail, and
unsubscribing when no subscription exists should say so rather than
reporting success.

Error Messages/Logs

Could not subscribe to this PR.

Steps to Reproduce

1. Have two Claude accounts (e.g. personal and work) connected to the same

GitHub identity, with the Claude GitHub App installed on a shared repo.

1. From a session on account A, create a PR (the standard flow subscribes

the creating session to the PR).

1. Start a Claude Code web session on account B, scoped to the same repo.
2. Call subscribe_pr_activity for that PR.
3. Observe "Could not subscribe to this PR." with no reason given.
4. From account A, unsubscribe (succeeds); retry step 4 — still fails.
5. Call subscribe_pr_activity for a nonexistent PR number — observe it

"succeeds".

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.201

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Platform detail: Claude Code on the web (Research Preview) — managed cloud
sessions started from claude.ai. The dropdowns above reflect the cloud
container environment (Linux 6.18.5, Ubuntu-based).

Impact: the "one session monitors/autofixes a batch of PRs" workflow is
completely unavailable cross-account, and the generic error gives the user
no way to diagnose it. Work+personal dual accounts are a common setup.

Possibly related: #65488 (session→PR binding set once, never re-resolved)
and #62977 (webhook event filtering) — same subscription subsystem,
different symptoms.