# Journey 3: Cursor IDE Power User

**Persona**: Solo Dev Sarah (Cursor variant)
**Challenge**: Cursor IDE aggressively binds ports on Windows
**Verified**: 2026-03-08 (Cursor squatting 17+ ports including default 11400)

## The Problem

Cursor IDE watches for new services and squats both `127.0.0.1:PORT` and `[::1]:PORT`, hijacking `localhost` traffic. On Windows, `localhost` resolves to `[::1]` first, so even if we bind `127.0.0.1`, Cursor's IPv6 bind steals traffic.

## How LLMHosts Handles It

1. **Connect-based port detection** -- probes both IPv4 AND IPv6 loopback (not bind-based, which lies on Windows)
2. **Specific binding** -- `127.0.0.1` instead of `0.0.0.0` (Windows routes specific > wildcard)
3. **IPv6 bridge** -- TCP relay on `[::1]:PORT` forwarding to `127.0.0.1:PORT`
4. **Adaptive scanning** -- if preferred port taken, scans +100 ports upward
5. **Result**: `curl http://localhost:PORT/health` always works, even with Cursor active

## User Configures Cursor

```json
{
  "openai.apiBase": "http://localhost:11402/v1",
  "openai.apiKey": "lh_sk_..."
}
```

## Success Criteria

- [ ] LLMHosts finds open port despite Cursor occupying 17+ ports
- [ ] Both IPv4 and IPv6 requests route to LLMHosts proxy
- [ ] Cursor can use the proxy as its AI backend
- [ ] No port conflict errors in logs

## Features Exercised

- Port detection (PR #436)
- Specific binding strategy
- IPv6 TCP bridge
- Adaptive port scanning

## Edge Cases

| Edge Case | Solution |
|-----------|----------|
| Cursor IDE squats ports | Connect-based detection + specific binding + IPv6 bridge |
| Windows `localhost` = `::1` | IPv6 TCP bridge forwards to real IPv4 server |
| Port 11400 pre-occupied | Adaptive scan: 11400 → 11401 → 11402 → ... |
