[BUG] Routine GitHub-event trigger fails: ccr_webhook_trigger "Repo is not associated with your organization"

Open 💬 0 comments Opened Jun 24, 2026 by ffesseler

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?

In claude.ai/code (web), saving a routine with a GitHub-event trigger on one specific repo always shows: "Routine saved, but the GitHub trigger couldn't be updated. Edit again to retry." Retrying never succeeds.

The browser network trace reveals the real underlying error, which the UI hides — the ccr_webhook_trigger endpoint returns a permission_error: "Repo is not associated with your organization."

The repo is fully accessible otherwise: the user is a repo admin, the Claude GitHub App is installed org-wide ("All repositories"), and a Schedule trigger on the SAME repo + routine works fine. Only the GitHub-event trigger fails, and only on this repo.

What Should Happen?

The GitHub-event trigger should register, as it does on sibling repos in the same GitHub org.

At minimum, the UI should surface the actual "Repo is not associated with your organization" permission_error instead of a generic "couldn't be updated," so users know it's an org-association problem and not a transient failure to retry.

Error Messages/Logs

{"error":{"message":"Repo is not associated with your organization.","resource":"ccr_webhook_trigger","type":"permission_error"},"request_id":"req_011CcNC5TmGAoJLHY7vBHNJX","type":"error"}

Reproduced by a second admin user on a different account, same error:
request_id "req_011CcNE5igvbA8GwXmbG9oG7"

Steps to Reproduce

  1. Connect a repo to Claude Code via the Claude Slack/GitHub integration ("Claude Tag"), which binds it to that integration's Claude workspace/org.
  2. In claude.ai/code, under a personal Claude account (a different org), create a routine targeting that repo.
  3. Add a GitHub-event trigger, e.g. "pull request ready for review", and save.
  4. UI shows: "Routine saved, but the GitHub trigger couldn't be updated. Edit again to retry." Network trace shows ccr_webhook_trigger permission_error: "Repo is not associated with your organization."
  5. Retry, reinstall the Claude GitHub App, and re-save the App's repository access. None clear it.
  6. Confirm that a Schedule trigger on the same repo works, and the same GitHub trigger on sibling repos in the same GitHub org works.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.186

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This is a Claude Code on the web (claude.ai/code) bug — browser-based. The version/os/terminal fields above are the reporter's local CLI env but are not where the bug occurs.

What's been ruled out:

  • Account: reproduced by a second repo-admin user on a different account.
  • Repo-admin permission: user is admin.
  • Default branch name: a sibling repo whose default branch is develop registers the trigger fine.
  • Repo size: a same-size sibling repo works.
  • Repo webhooks: repo Settings -> Webhooks list is empty, and GitHub App events do not appear there anyway.
  • Repository rulesets: none on any repo.
  • GitHub App coverage: org install = All repositories, confirmed.
  • GitHub App reinstall plus re-save of repository access: neither cleared it, suggesting the broken link is in Claude's backend, not GitHub.

Likely cause: the repo was first connected via the Claude Slack integration, which binds it to that integration's Claude org. Routines created under a different personal Claude org then fail the ccr_webhook_trigger org-association check.

There is no UI to view or change a repo's Claude-org association, so this is not self-serve fixable.

Net: two distinct issues:

  1. The org-association check blocks a repo the user has full GitHub access to and created the environment for.
  2. The web UI hides the specific permission_error behind a generic "couldn't be updated," making it undebuggable without devtools.

View original on GitHub ↗