[BUG] i = -1 infinite loop pattern was introduced. debugging session misdiagnosed the root cause as server-side for ~3 hours

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?

A Claude Code session introduced an infinite for loop in a React sidebar component (AppSidebar.jsx) while implementing a nav ordering feature. The loop used i = -1 to restart iteration on every successful array reorder, which never terminated when module configurations couldn't stabilize. This froze the browser's JS main thread on every page load after authentication, making the entire application unusable.

When a subsequent session was asked to debug the issue, it spent ~3 hours and significant API credits investigating server-side causes (middleware conversion, uvicorn worker count, keep-alive settings, response headers, GIL contention, Starlette response streaming) before finally checking the React rendering code. The actual fix was a 10-line bounded loop replacement.

What Should Happen?

1. Claude Code should never introduce unbounded loop restarts (i = -1, i = 0 inside a for loop) without a maximum iteration cap. This is a basic infinite loop pattern that any code review would flag.

1. When debugging a "page unresponsive" browser error, Claude Code should recognize this as a client-side JS infinite loop and check the React rendering code first — not spend hours on server diagnostics when the server is clearly returning 200 OK for all requests.

1. The debugging session had clear evidence early on that the server was fine (concurrent curl returned 200 in <100ms for all endpoints), yet continued pursuing server-side theories for over 2 hours.

1. I need a refund of my usage and extra usage. I used almost $20 extra usage debugging something that should never have happened.

Error Messages/Logs

**User-facing:** Chrome "Page Unresponsive" dialog after login — options: "Exit page" or "Wait"

**Server logs showed all requests succeeding:**

INFO: 172.18.0.7:46252 - "GET /api/auth/me HTTP/1.1" 200 OK
INFO: 172.18.0.7:46278 - "GET /api/favorites HTTP/1.1" 200 OK
INFO: 172.18.0.7:46248 - "GET /api/config HTTP/1.1" 200 OK


**The problematic code (introduced by Claude Code):**

// AppSidebar.jsx line 160-171
for (let i = 0; i < groups.length; i++) {
    // ... reorder logic ...
    groups.splice(i, 1)
    groups.splice(newTarget + 1, 0, g)
    i = -1 // ← INFINITE LOOP: restarts from beginning every time
}

Steps to Reproduce

1. Have Claude Code implement a feature that reorders array items with "chained hint" support
2. Claude generates a for loop that uses i = -1 to restart after each successful move
3. Deploy to production — the site becomes completely unresponsive after login
4. Ask Claude Code to debug the issue
5. Observe it spend 3+ hours investigating server-side causes (middleware, workers, keep-alive, response streaming) despite all server endpoints returning 200 OK
6. Eventually, after exhausting server theories, it checks the React code and finds the infinite loop it introduced

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.100

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

• The bug was introduced on Apr 9, 2026 during a feature implementation session and discovered on Apr 10, 2026
• The project had no git version control, so there was no way to quickly revert — Claude Code sessions had not suggested setting this up despite extensive ongoing development
• Total downtime: ~3+ hours of complete inaccessibility
• Total debugging credits wasted: ~3 hours of Opus-tier API usage on incorrect server-side investigation
• The correct diagnosis (searching for i = -1 in recently modified JSX files) would have taken <5 minutes
• Key missed signal: early Puppeteer tests showed /settings route worked but / (home) didn't — both share the same AppLayout with the sidebar. This should have immediately pointed to the sidebar or the index page component, not the server
• Another missed signal: the browser's "Page Unresponsive" dialog definitively indicates a JS main thread block, not a network/server issue