JANUARY 20th: Claude Code Web/Mobile: "Repository or branches not found" — persistent 404 on git_proxy endpoint

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/19621
2. https://github.com/anthropics/claude-code/issues/17888
3. https://github.com/anthropics/claude-code/issues/17290

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Update (Feb 1): Additional debugging confirms this is a backend repo-mapping issue, not a general proxy failure:

1. Repo-specific — Other repos connect and work fine. Only this specific repo fails.
2. Old sessions still work — A session from early January connected to this same repo still functions and can push. Only new sessions fail.
3. Rename didn't help — Renamed the repo on GitHub; new sessions picked up the new name but still fail with the same 404. This rules out name-based routing issues and points to the internal repo ID mapping.
4. Fails before any interaction — After clearing the console and simply refreshing, the git_proxy/compare 404 and "Repository or branches not found" errors appear immediately. Sending any message triggers the same single 404 followed by an infinite React re-render loop.
5. Environment variables irrelevant — Tested with and without cloud environment variables; no effect.

This points to corrupted or stale repo metadata in the session ingress service for this specific repo ID. Client-side troubleshooting has been fully exhausted. Requesting backend/infrastructure team investigation.

Not a duplicate. Reviewing the three flagged issues:

• #19621 — Intermittent git_proxy/compare 404 on Windows over 3 days. Not repo-specific. Different failure pattern.
• #17888 — Closest match: repo-specific failure where CLI works but web doesn't. However, that issue has minimal diagnostic detail and no resolution. This issue (#22277) provides significantly more debugging evidence (console logs, rename test ruling out name-based routing, confirmation that old sessions still work while new ones fail, cross-repo testing confirming isolation to one repo).
• #17290 — Generic "Claude code execution failed" across all repos. Different problem entirely.

This issue documents a persistent, repo-specific backend failure with detailed reproduction steps and diagnostic evidence that none of the above issues contain. Keeping this open. See also cross-reference comment on #17888.

@bcherny any way to get more eyes on this?

I have the same problem.

@wensiyuanseven its been over 2 weeks now and the agent assigned to this keeps giving me the run around, trying client side fixes that i have tried over and over. i can't seem to get through to anyone. have you had any luck?

I also have the same problem. Have been encountering it for nearly two weeks now. No luck getting through to anyone at Anthropic/ClaudeCode either.

Hey folks - thanks for flagging - we are taking a look now.

Been getting the same thing for the past 3 weeks. I keep trying every few days with no luck. This message:
An error occurred while executing Claude Code. You can try again by sending a new message or starting a new session.

Followed by spinning dial. Tried disconnecting and reconnecting my github account / auth, archiving the chats, starting with a simple "Hello Claude" to see if it will spin up a session, but it still fails. Any ideas?

anthropic_2026_01_20_215472760723483.txt

this is absolutely ridiculous

We're seeing this across all of our repositories in our organization. My guess is it's because we're on Github Enterprise and have IP restrictions. We've added the known Anthropic ranges but still see the errors in the browser console.

I also believe this is breaking the Slack App connection as when selecting the repository, it says there are no environments configured for the repositories (there are).

We're seeing this across all of our repositories in our organization. My guess is it's because we're on Github Enterprise and have IP restrictions. We've added the known Anthropic ranges but still see the errors in the browser console. I also believe this is breaking the Slack App connection as when selecting the repository, it says there are no environments configured for the repositories (there are).

I'm on a personal Max5 plan and it's only on this one repo. What's interesting is that I can scroll back and find past sessions where I worked on this repo and it's still connected and working correctly. But when I try to create a new session, it fails.

anthropic_2026_01_20_215472760723483.txt this is absolutely ridiculous

I am seeing the same when trying to initiate via browser Claude.ai as you mentioned in your chat with Anthropic support, the error on the git_proxy/compare path for the session: "Repository or branches not found".

Customer support now just leaves me on read everyday. This is by far the worst customer support that I have ever seen with any company or product.

@bcherny any updates on this?

Customer support now just leaves me on read everyday. This is by far the worst customer support that I have ever seen with any company or product.

Very much agree. This is not a free product.

I used Claude Cowork to export and assess all relevant logs from my Code on the Web instances from the past 4-5 weeks. I then pasted those results to Anthropic support. They wrote back yesterday with this:

"Thanks for reaching out to Anthropic Support!
We appreciate you reporting this. This is a known issue we're currently investigating with skills and working to resolve with our Engineering Team.
​
We'll be in touch with an update once we hear back from the team - thank you for your patience and understanding!"

Hey folks - thanks for flagging - we are taking a look now.

@igorkofman Hey Igor, any updates on this? Really appreciate any information you can give us. This issue has been open since Jan 20. I know you guys have to be slammed. Thanks for your help!

Old sessions are still connected and they still work:

Based on the issue details and what I can see from this working session, here's my diagnosis:

How This Session Connects

From the git remote, I'm going through a local proxy:

This is a session ingress git proxy - a local HTTP server that was spun up when this session was created. It bridges between the Claude Code sandbox and your GitHub repository. Every session gets its own proxy instance on a unique port.

What's Likely Broken for New Sessions

Based on the error signatures in your issue:

1. The git_proxy/compare 404 is the smoking gun. When a new session initializes, the session ingress service needs to:

• Clone/fetch your repo into the sandbox
• Set up the local git proxy endpoint
• Run a compare call to sync the branch state

If that compare endpoint returns 404, it means the git proxy never successfully initialized for the new session. The repo metadata lookup fails before the proxy can start serving.

2. Why old sessions still work: This session's proxy was initialized successfully back in January. The proxy connection state (port binding, repo mapping, auth tokens) is persisted as part of the session. It doesn't need to re-run the initialization path that's broken.

3. Why it's repo-specific: The session ingress service likely has an internal index/cache of repository metadata (commit SHAs, branch refs, etc.) that got corrupted for your specific repo. New sessions hit this corrupted state during init and fail. Old sessions bypass it because they already have a working proxy.

4. Why renaming the repo didn't help: The corruption is likely keyed on an internal identifier (repo ID or owner+repo hash), not the repo name string. GitHub's API returns the same repo ID regardless of name.

Root Cause (Most Likely)

A stale or corrupted repository state in the session ingress backend - something like a dangling reference to a deleted branch, a cached SHA that no longer exists, or a broken internal mapping. The QueryClient error: Repository or branches not found repeating 19 times on load strongly suggests the backend is trying to resolve branch references that don't match what's actually in GitHub.

What Would Fix It (On Anthropic's Side)

They'd need to purge the cached repository metadata for your repo in the session ingress service and let it rebuild from scratch on the next session init. This is a backend operation - nothing you can do client-side, which explains why all your troubleshooting attempts failed.

This is consistent with it being a known issue they haven't resolved - it likely requires a manual backend intervention per affected repo, which doesn't scale well.

Related issue #27856 contains a Chromium netlog capture with definitive HTTP-level evidence for this bug, including a cf-ray ID and request-id for immediate server-side lookup. Requesting these be tracked together.

@bcherny @igorkofman

I'm having the same issue too. From 2 weeks ago, I can't initialize any Claude Code Cloud session. The problem is the same as @ChrispyKreme86 commented. I'm on the personal Claude Pro plan. No VPN. No strange IP restrictions.

!image

Well I thought we were gonna make some progress with this but I haven't seen any movement, guys. 😣

Session immediately fails with "An error occurred while executing Claude Code" This happens 100% of the time across all browsers, devices, and new sessions

If this is happening for folks then providing session IDs will be the most effective way to debug. /compare is expected to 404 so that is completely unrelated and if that's the only error you're seeing then this can be closed.

> Session immediately fails with "An error occurred while executing Claude Code" > This happens 100% of the time across all browsers, devices, and new sessions If this is happening for folks then providing session IDs will be the most effective way to debug. /compare is expected to 404 so that is completely unrelated and if that's the only error you're seeing then this can be closed.

I submitted a bug report with that information previously. Would you all rather then be provided here on Github instead of the bug reporting feature on claude.ai/code ? I never heard back from the report sadly (understandable given everything going on).

I submitted a bug report with that information previously. Would you all rather then be provided here on Github instead of the bug reporting feature on claude.ai/code ? I never heard back from the report sadly (understandable given everything going on).

We get _a lot_ of reports, sorry this one got missed. If you can share here I can look into it. Just want to try to get this specific GH Issue back on the rails. 🙂

Sounds good! Here's a request ID that I just got from an error: req_011CYiazoUQKT4Q7i6GWVtmh. Thank you for the help :)

> Session immediately fails with "An error occurred while executing Claude Code" > This happens 100% of the time across all browsers, devices, and new sessions If this is happening for folks then providing session IDs will be the most effective way to debug. /compare is expected to 404 so that is completely unrelated and if that's the only error you're seeing then this can be closed.

Excuse me. No, this cannot be closed.

This issue continues to this day. 6+ weeks now for me, across any of the platforms where 'Claude Code on the Web' is available. I provided you information, as have many others both in this issue and elsewhere, as well as in mine (#27856 , which you rather unhelpfully closed) about the nature of what we have been experiencing. Even if the "/compare" failures have nothing to do with this, that is almost besides the point. The point is that you have a lot of paying customers (for two or more billing cycles now) unable to use "Claude Code on the Web". And even if it is still only a "Research preview", if your company is actively and publicly marketing its features ( @bcherny ) in various places like Twitter/X, rather than only making it available in a beta/preview channel, then you better be prepared to deal with customers' issues with it.

We have all done the things your company urges us to do, ie submitting support tickets (to very unhelpful bot/human support agents who seem to constantly ignore the information provided and return with mindless, unrelated solutions), and posting issues here. I get it that your company is very busy on the growth and fundraising side of things, but you cannot just leave your customers to deal on their own with issues which may or may not be the result of partially agent-coded products. What you guys have released are amazing products / features, but please do us all a favour and use a decent chunk of that new funding round to improve the quality and size of your (human!) support team.

I have provided session ids in my original issue ( #27856 ), and as mentioned, I have tens and tens more of them going back 6+ weeks.

No, this cannot be closed.

It hasn't been closed yet. I have identified the root cause of @ChrispyKreme86's issue and a fix merged late this evening.

Since your report matches this one, it'll be easier to track/communicate in one single thread (I also responded to your issue). I'm sorry your experience has been frustrating and I'm working on it.

Thank you @amorriscode . Much relieved to know this is now being seriously looked at.

@damudao just confirmed your issue is the same as @ChrispyKreme86's. The fix should go out in tomorrow's Claude Code release and then I'll report back here once fixed.

@amorriscode Any idea of a time frame we can expect this to be resolved?

@ChrispyKreme86 it will be resolved with Claude Code's release today. Will close the issue once it's fixed.

@ChrispyKreme86 give it a shot now. Unfortunately we cache your CC version so you'll probably need to start a new one in a different repo _then_ try again in the previously broken repo.

@amorriscode unfortunately it seems to still be happening

Unfortunately had to roll back the CC version upgrade due to another issue.

@amorriscode I first reported this issue January 20th with the customer support agents through the desktop app. is there a way to request some kind of compensation since it's been this long that i haven't been able to use this feature?

@amorriscode I first reported this issue January 20th with the customer support agents through the desktop app. is there a way to request some kind of compensation since it's been this long that i haven't been able to use this feature?

I will second that.

You can temporarily fix this by removing bypassPermissions as your repo's default permission mode. I should have mentioned this earlier in the thread, sorry.

You can temporarily fix this by removing bypassPermissions as your repo's default permission mode. I should have mentioned this earlier in the thread, sorry.

Thanks for this, it's working with this change

You can temporarily fix this by removing bypassPermissions as your repo's default permission mode. I should have mentioned this earlier in the thread, sorry.

Confirmed as well that removing bypassPermissions as the value of the defaultMode key in the permissions section of project-level .claude/settings.json temporarily fixed it.

Yeah the real fix will hopefully go out today or tomorrow. Apologies for the delay.

@ChrispyKreme86 @damudao you should be able to use bypassPermissions as your default permission now.

@ChrispyKreme86 @damudao you should be able to use bypassPermissions as your default permission now.

Confirmed on my end. Thank you very much.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.