[BUG] Claude Code Web: persistent 404 on session_ingress/.../git_proxy/compare — every session fails to initialize

Found 3 possible duplicate issues:

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

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

Found 3 possible duplicate issues: 1. JANUARY 20th: Claude Code Web/Mobile: "Repository or branches not found" — persistent 404 on git_proxy endpoint #22277 2. [[BUG] Claude Code hangs when Git branch comparison is triggered #19621](https://github.com/anthropics/claude-code/issues/19621) 3. [[BUG] An error occurred while executing Claude Code #17888](https://github.com/anthropics/claude-code/issues/17888) 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

This is not a duplicate — it provides evidence that the existing issues lack.
#22277 describes symptoms. This issue provides the Chromium netlog capture with the actual HTTP request timeline proving the root cause: POST /v1/session_ingress/.../git_proxy/compare → HTTP 404, x-should-retry: false, x-envoy-upstream-service-time: 282. Every other request in the session succeeds. The Sentry trace ID, request-id, and cf-ray are included for immediate server-side lookup.
#22277 has been open for 3 weeks with no resolution. #17888 is from January 13 — over 5 weeks. Closing this removes the only report with actionable HTTP-level debugging data.
If consolidation is preferred, please merge this evidence into #22277 rather than closing.

Hey! I ran into a similar pattern in our bug knowledge base and thought this might help.

What's happening: After successful session creation (POST /v1/sessions → 200), the client sends the session_id to the git_proxy/compare endpoint, but the server-side path validator rejects it with 'path.conversation_uuid: Input should be a valid UUID'. This indicates a parameter naming mismatch: the route expects a path parameter named 'conversation_uuid' but the client is sending a 'session_id'. Either the server route definition was updated to expect conversation_uuid while the client still sends session_id, or the session object returned by /v1/sessions contains an ID that doesn't match the UUID format the git_proxy route validates against. The x-envoy-upstream-service-time: 282ms confirms the request reaches the upstream service (not dropped at the edge), so the 404 is generated by the application layer's path parameter validation, not by a missing route.

What worked for us:

This is an Anthropic server-side issue. The git_proxy route's path parameter validation expects a 'conversation_uuid' but the client is providing a 'session_id' (possibly in a different format or under a different path segment name). The fix requires Anthropic to either: (1) update the git_proxy route to accept session_id as the path parameter and map it internally to conversation_uuid, or (2) ensure the session creation response includes a conversation_uuid that the client should use for subsequent git_proxy calls instead of session_id. The 100% repro rate across all platforms and the month-long duration suggest a server-side deployment regression.

Steps:

1. Report to Anthropic: the POST /v1/session_ingress/session/{session_id}/git_proxy/compare endpoint returns 404 because path validation expects 'conversation_uuid' but receives 'session_id'
2. Server-side fix needed: align the git_proxy route parameter name with what the client sends, or return the correct UUID in the session creation response for the client to use
3. Workaround: none available — this is entirely server-side infrastructure; users cannot fix this locally
4. Monitor duplicate issues #22277, #19621, #17888 for official Anthropic response or status updates

No client-side patch possible. Server-side fix required at Anthropic:

// Option A: Fix route definition to accept session_id
// Before: router.post('/v1/session_ingress/session/:conversation_uuid/git_proxy/compare', validate({conversation_uuid: UUID}), handler)
// After:  router.post('/v1/session_ingress/session/:session_id/git_proxy/compare', validate({session_id: UUID}), handler)

// Option B: Map session_id to conversation_uuid in middleware
// app.use('/v1/session_ingress/session/:id/git_proxy/*', (req) => { req.params.conversation_uuid = req.params.id; })

Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞

_Disclosure: This analysis is from Confucius Debug, an AI-powered community KB for agent bugs. Please verify before applying._

---
_{🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.}

Following up on the original report with some additional / supporting diagnostic evidence from testing today. This covers: a netlog analysis of the failure, a GitHub disconnect/reconnect test, and a finding about which repos fail and which don't.

---

The failure is repo-specific, tied to prior Claude Code Web usage

Today I tested fresh/old repos that have never been used with Claude Code Web. They loaded and initialized successfully — sessions started, code ran, everything worked.

I then tested two repos that I had previously been actively working on via Claude Code Web ~3 months ago (when the feature was still functioning for me). Those repos failed with the exact same git_proxy/compare 404.

Pattern:

• Repos with no prior Claude Code Web history → work fine
• Repos that were previously used with Claude Code Web (before the breakage ~2 months ago) → fail 100% of the time

This aligns with what @ChrispyKreme86 found in #22277: old sessions from early January still functioned, but new sessions targeting the same repo failed. It also aligns with their finding that renaming the repo on GitHub didn't help — the server-side metadata is keyed to something other than the repo name.

This suggests there may be stale repo metadata in the session ingress service for repos that were onboarded before a backend change around late December 2025 / early January 2026. New repos get the current format and work. Old repos appear stuck with the old format.

---

GitHub disconnect/reconnect test — no effect

During today's session I performed a controlled test:

1. Disconnected GitHub in Settings → Connectors on claude.ai
2. Attempted a code session while disconnected — got an immediate yellow warning ("GitHub is not connected") followed by: An error occurred while processing git_repository source
3. Reconnected GitHub via the OAuth re-authorization flow
4. Attempted a code session again on the same previously-used repo — exact same failure as before

The client-side logs confirmed the reconnection worked at the API level: no more "GitHub authentication required" errors, branches loaded, repo metadata synced. But the git_proxy/compare call still returned 404.

Conclusion: The GitHub OAuth token and App installation are not the issue. The failure is deeper in the session ingress / git proxy layer.

---

Netlog analysis

Captured a Chromium netlog during a session startup attempt. Here is the request timeline:

Requests that succeeded (all HTTP 200):

| # | Method | Endpoint | Purpose |
|---|--------|----------|---------|
| 1 | POST | /v1/sessions | Session creation |
| 2 | GET | /v1/sessions/{id}/share-status | Share status check |
| 3 | GET | /v1/sessions/{id}/events | Event history |
| 4 | POST | /v1/sessions/{id}/events | Event posting |
| 5 | POST | /api/organizations/{org}/code/repos/resync | Repo resync |
| 6 | GET | /api/github/organizations/{org}/github/{owner}/{repo}/branches | Branch listing |
| 7-9 | POST | /v1/code/github/batch-branch-status | Branch status (×3) |
| 10 | GET | /v1/environment_providers/private/organizations/{org}/environments/{env} | Environment config |
| 11 | GET | /v1/environment_providers/private/organizations/{org}/environments | Environment listing |

WebSocket — succeeded:

| Method | Endpoint | Result |
|--------|----------|--------|
| GET→101 | wss://claude.ai/v1/sessions/ws/{id}/subscribe?organization_uuid={org} | WebSocket upgraded, 13 frames exchanged |

The single failure:

| Method | Endpoint | Result | Headers |
|--------|----------|--------|---------|
| POST | /v1/session_ingress/session/{id}/git_proxy/compare | HTTP 404 | x-should-retry: false, x-envoy-upstream-service-time: 282 |

Key identifiers for server-side tracing:

• Request ID: req_011CYaXTwAmYpZ35YNVpvGQa
• Cloudflare Ray: 9d502db0dcbfef74
• Session ID: session_01BKwuv28WfNfRGjexiS6Ufb
• Organization: (can provide privately if needed for tracing)

The x-envoy-upstream-service-time: 282ms indicates the request reached the upstream service and was processed — not a routing/proxy timeout. The service returned 404 intentionally.

---

Client-side log analysis

Analyzed three sets of exported Claude app logs from today's session. Key observations:

claude.ai-web.log: No specific error is logged for the code session failure. The client receives the 404 and surfaces the generic error banner. The only related errors are:

• Recurring path.conversation_uuid: Input should be a valid UUID, invalid character: expected 'urn:uuid:' followed by [0-9a-fA-F-], found 'l' at 1 — this appears throughout the log history, suggesting a systemic ID format mismatch
• React hydration errors (error code 418) on every page load

main.log: Shows dozens of lam_session_start_attempted events (20+ on Jan 30 alone), confirming the repeated start-fail-retry pattern over weeks.

claude.ai-web1.log: Shows Failed to fetch branch statuses: 400 from Jan 19 — possibly the earliest manifestation of the backend issue.

---

Summary of what we now know

| Question | Answer |
|----------|--------|
| Is it client-side? | No. Happens on macOS, Windows, iOS, and web browser. |
| Is it the GitHub connection? | No. Disconnect/reconnect had no effect. API-level GitHub calls all succeed. |
| Is it account-wide? | No. Fresh repos that never touched Claude Code Web work fine. |
| Is it repo-specific? | Yes. Only repos previously used with Claude Code Web before the breakage fail. |
| What exactly fails? | POST /v1/session_ingress/session/{id}/git_proxy/compare → HTTP 404 |
| Is it transient? | No. x-should-retry: false. 100% reproducible for ~2 months. |
| Does the CLI work? | Yes. Claude Code CLI works perfectly with the same repos. |

---

Possible root cause

Something appears to have changed in the backend around late December 2025 / early January 2026 — possibly a migration, schema change, or data format update in the session ingress / git proxy service. This may have broken stored metadata for repos that had been used with Claude Code Web before the change. New repos get created with the current format and work. The old metadata doesn't appear to get cleaned up or migrated.

The recurring UUID validation error (found 'l' at 1) in the client-side logs suggests a possible ID format mismatch between what the client sends and what the route handler expects, but this alone doesn't explain why new repos work — unless the metadata lookup happens first and the 404 is actually "repo metadata not found in current schema" rather than "invalid URL parameter."

---

Related issues

• #22277 — Same bug, reported Feb 1 by @ChrispyKreme86 (started Jan 20). Confirmed repo-specific. Still open.
• #17888 — Same symptoms, reported Jan 13. Earliest known report.
• #18452 — Closed as duplicate of #17888
• #23073 — Closed as duplicate of #22277
• #24215 — "Opus stuck on web" — Feb 8, likely related
• #24106 — --teleport fails with session_ingress 403 — related infrastructure

This has been affecting multiple users for over two months. Would appreciate any visibility into whether the infrastructure team is aware of this. Happy to provide additional logs or testing if helpful.

Great catch @damudao — the repo-specific angle is a big piece we missed.

Looking at your evidence again, the failure pattern becomes clearer:

Updated root cause: The 404 on git_proxy/compare isn't just a parameter naming issue — it's tied to stale server-side session/repo state from prior Claude Code Web usage. Fresh repos (never used with Claude Code Web) work fine because there's no leftover state to conflict with.

The likely sequence:

1. Session creates successfully (POST /v1/sessions → 200) ✅
2. Client calls git_proxy/compare with the session_id
3. Server tries to resolve the repo's git state but hits stale metadata from a previous Claude Code Web session (months old)
4. The stale metadata causes the path validator to reject with 404 (x-should-retry: false)

This explains why disconnecting and reconnecting GitHub doesn't help — the stale state isn't in the GitHub OAuth token, it's in Anthropic's server-side repo association cache.

Workaround candidates to test:

• Create the session on a fresh clone of the same repo (different local path)
• If the API supports it, explicitly delete/reset the server-side repo association before starting a new session

Unfortunately vibe diagnosing the issue isn't helpful. /compare is expected to 404 and has nothing to do with sessions on the container. 🙂

Closing in favour of https://github.com/anthropics/claude-code/issues/22277. If you have specific session IDs (found in the URL when loading a session) you can send them there or contact me directly.

Unfortunately vibe diagnosing the issue isn't helpful. /compare is expected to 404 and has nothing to do with sessions on the container. 🙂 Closing in favour of #22277. If you have specific session IDs (found in the URL when loading a session) you can send them there or contact me directly.

With all due respect @amorriscode , when you as a team leave this issue standing for as long as you have (6+ weeks now), with absolutely ZERO in terms of useful communication and feedback via the formal support channels and utter silence here and on related issues, and to paying customers no less, then I would have thought you ought be somewhat more humble about how you respond to customers' own efforts to triage the issues. I also previously had to follow-up with direct emails to all of your senior management (including @bcherny ) as to this situation, as well as a now resolved Windows Cowork VM issue, as it is outrageous and unacceptable.

By the way, if you had genuinely taken the time to review the information I provided here, you would see that I did provide a session ID to investigate. For your convenience, though frankly I am no longer feeling so generous, I provide it again now: "Session ID: session_01BKwuv28WfNfRGjexiS6Ufb". And here is another from just today: "session_01L1AkFKmktKqzp1Mi6xgLKF". I could provide you another 50+, but that would take me back over 6 weeks+ ... yes, you heard that right.

@damudao sorry about that, I know it's frustrating that you haven't heard back in weeks and I'm sincerely sorry about that. I didn't see this issue until today and I'm working on it now. You're right that I missed the session IDs.

That being said, this report was the same as #22277 with the same incorrect diagnosis about the /compare endpoint. Consolidating them makes it easier to do comms. These issues cannot be debugged via the client unfortunately but I am looking into your sessions.

Understood. Thank you @amorriscode

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.