You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature]: expose "waiting on user input" on the session, not just status=running
#18032
A turn that is blocked on a question (Claude AskUserQuestion, or an approval) reports session.status = "running" with an activeTurnId. On the session it is indistinguishable from a turn that is doing work. The only signal is the shell's hasPendingUserInput / hasPendingApprovals (and the client's "Awaiting Input" label).
So an API consumer that reads the session alone treats a parked turn as live work. In our case these consumers were a weekly restart check that waits for "no turn in progress", a delivery worker that waits for the thread to go idle, and a stall detector. One day three turns sat parked on questions for 18 to 24 hours, and each consumer read them as busy the whole time.
Ask
Expose the waiting state on the session or the thread detail. Either:
a distinct session status (for example waiting); or
a field next to activeTurnId, e.g. waitingOn: "user-input" | "approval" | null.
With that, automation can tell "working" from "parked" without reading the shell and joining it by thread id.
Related
#15258 is the complementary case. There, an async question makes a thread that is still working show as Awaiting Input. A field that separates "blocked on the answer" from "question open, still working" would serve both.
This discussion was converted from issue #15900 on October 11, 2026 01:41.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Area
apps/server (orchestration read model, thread detail / shell API)
Problem
A turn that is blocked on a question (Claude
AskUserQuestion, or an approval) reportssession.status = "running"with anactiveTurnId. On the session it is indistinguishable from a turn that is doing work. The only signal is the shell'shasPendingUserInput/hasPendingApprovals(and the client's "Awaiting Input" label).So an API consumer that reads the session alone treats a parked turn as live work. In our case these consumers were a weekly restart check that waits for "no turn in progress", a delivery worker that waits for the thread to go idle, and a stall detector. One day three turns sat parked on questions for 18 to 24 hours, and each consumer read them as busy the whole time.
Ask
Expose the waiting state on the session or the thread detail. Either:
waiting); oractiveTurnId, e.g.waitingOn: "user-input" | "approval" | null.With that, automation can tell "working" from "parked" without reading the shell and joining it by thread id.
Related
#15258 is the complementary case. There, an async question makes a thread that is still working show as Awaiting Input. A field that separates "blocked on the answer" from "question open, still working" would serve both.
Version
0.0.43-nightly.20260919.1948 (Linux x64, provider
claudeAgent). I haven't yet checked whether Orchestrator v2 (#2829) changed this.All reactions