[Bug] Session timeout silently terminates /ultraplan while UI remains active, losing unsaved feedback
Bug Description
Title: /ultraplan browser UI accepts feedback into an already-terminated session, then loses it on submit
What happened:
I ran /ultraplan on a non-trivial planning task. The session terminated server-side after 90 minutes with "no
approval." because I took my dog for a walk. I didn't see that in the browser — the feedback composer remained active and editable. I spent ~20 minutes writing detailed feedback on the plan. When I hit submit, the API returned:
{
"error": {
"message": "Cannot send events to inactive session: session_01DPsH1geoW9EQfYnRFvHtxq",
"reason": "",
"type": "invalid_request_error"
},
"request_id": "req_011Ca4gHW6jnkm4gjvSrQ29n",
"type": "error"
}
The error had no recovery path and my 20 minutes of feedback were lost.
Expected:
Any of these would have prevented the data loss:
- The browser should disable the composer (or show a clear banner) as soon as the session goes inactive, so I
can't waste time writing into a dead session.
- Feedback drafts should be persisted client-side (localStorage) so a failed submit — for any reason —
doesn't destroy the work.
- On submit failure, the UI should keep the composer contents and offer retry / copy-to-clipboard, not just
surface a raw API error.
- User activity in the composer should extend the session timeout, or the timeout should be much longer than
90 minutes given the "async" framing.
Actual:
- Session terminated silently in the background while the UI still looked live.
- Composer accepted 20 minutes of typing into a session the server already considered dead.
- Submit returned invalid_request_error with no retry, no draft preservation, no export.
- All feedback lost, plus the tokens spent generating the plan.
Impact:
The core value prop of /ultraplan is async inline feedback on a plan. A 90-minute wall clock doesn't match
"async" — real review cycles (walk away, come back, think) routinely exceed that. And …
Note: Content was truncated.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗