Why Cursor Composer’s Context Loss Cost Us a Production Deploy — And the 90-Minute Hard Limit We Now Enforce

TL;DR: Cursor Composer forgets running dev servers, tunnels, and DB connections after 60–90 minutes. During a production Stripe migration, it lost context twice — 45 min recovery. We now enforce a 90-min Cursor limit via timer alias; longer sessions auto-switch to Codex. Incident timeline →

The Context

Two-dev team. Cursor Pro since Jan 2026. Composer was our daily driver. Known issue: “Composer forgets context after a while” — but we’d only seen it on 2+ hr sessions. Assumed it was manageable. May 15, 2026 proved otherwise.

The Incident: Stripe Webhook Migration (May 15, 2026)

Time	Event
10:00	Start migration: 14 files, new webhook handler, idempotency keys
10:05	stripe listen --forward-to localhost:3000/webhook (PID 8472)
10:07	supabase db reset && supabase db seed — test data loaded
10:15–11:30	Composer edits across 14 files; tests passing
11:32	Composer stops responding; tunnel PID 8472 gone; Supabase connection dropped
11:32–11:45	Recovery 1: Restart tunnel, reseed DB, re-explain schema, resume
11:45–12:40	Continue edits; Composer seems stable
12:42	Second context loss: tunnel + DB gone again
12:42–12:57	Recovery 2: Same drill; morale tanked
12:57–13:30	Finish migration in Codex (persistent) — zero further losses
13:30	Deploy to staging → production. 45 min lost to context recovery.

Root cause: Composer’s context window management drops terminal state (PIDs, connections) when conversation history exceeds internal threshold (~90 min of active interaction). Not documented; discovered empirically.

What We Tested After

Tool	Session Length	Context Loss?	Notes
Cursor Composer	60 min	✅ None	Safe zone
Cursor Composer	90 min	⚠️ Intermittent	Boundary
Cursor Composer	120+ min	❌ Consistent	Unusable
Codex (persistent)	5 hrs	✅ Never	Survives full day
Claude Code	3 hrs	✅ Session-only	But no persistence across restarts
Windsurf Cascade	3 hrs	✅ None	Good alternative

The Pivot Point

May 15, 12:57 PM: Finished migration in Codex. Realized: we’d been treating Cursor as “the IDE” when it’s actually “the <90-min editor.” Built the guardrail that day.

What We Use Now

Hard 90-min Cursor limit (enforced via timer alias in shared dotfiles):

# ~/.config/chezmoi/dot_zshrc.tmpl
alias cursor='cursor-timer'
cursor-timer() {
  local limit=90  # minutes
  echo "⏱️  Cursor session limit: ${limit}min. Switch to 'cx' (Codex) for longer work."
  command cursor "$@" &
  local pid=$!
  (sleep $((limit * 60)) && notify-send "⚠️ Cursor 90-min limit reached. Save context & switch to 'cx'." && kill -USR1 $pid 2>/dev/null) &
}

Team Protocol (in AGENT_WORKFLOW.md):

• Cursor: < 90 min only — quick edits, type-heavy work, LSP-dependent TS
• 90-min timer fires → save, commit, switch to cx (Codex)
• No exceptions. Two violations = Cursor removed from dock for a week (peer enforced).

Result: Zero context-loss incidents since May 15. Cursor still used daily — but only for what it wins at.

When You’d Choose Differently

• Solo dev, short sessions only: Cursor alone is fine; no guardrail needed.
• TypeScript-heavy codebase: Cursor’s LSP integration catches errors mid-edit — worth the 90-min dance if your sessions are naturally short.
• Teams using Cursor Business: Admin can’t enforce session limits; relies on culture.

Tool Crucible Rating

Dimension	Rating (1–5)	Notes
Overall	3	Great <90 min; hard ceiling after
Ease of Use	4	Best IDE integration; timer alias trivial
Value	3	$20/mo for <90-min tool; need 2nd tool for long work
Support	3	Context loss known issue; no timeline for fix

---

This is part of our AI Coding Tool Evaluation series. See incident timeline: Cursor Composer Context Loss: The 90-Minute Hard Limit We Enforce