[Bug]: Cannot archive Thread that's waiting for input

[fajare]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Start a session/thread
2. Claude Code or GPT ask questions, given the thread a "Awaiting Input" tag
3. No way for me to archive the conversation, without answering the question

I come across this issue quite often, as the questions that Claude/GPT ask, immediately let me know that i prompted into a wrong/different direction than i originally wanted to. I would rather open a new thread in these cases, instead of first having to answer the questions and then steer the thread to my original idea.

Expected behavior

On hover the thread should show the archive icon in the sidebar navigation, just like all other thread types.

Actual behavior

1. Start a session/thread
2. Claude Code or GPT ask questions, given the thread a "Awaiting Input" tag
3. No way for me to archive the conversation, without answering the question

I come across this issue quite often, as the questions that Claude/GPT ask, immediately let me know that i prompted into a wrong/different direction than i originally wanted to. I would rather open a new thread in these cases, instead of first having to answer the questions and then steer the thread to my original idea.

Impact

Minor bug or occasional failure

Version or commit

No response

Environment

No response

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[juliusmarminge]

Archiving is now blocked only for an actively running turn; a thread waiting for user input is not treated as running, and its sidebar archive action remains available.

This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.

[TomasDzY]

I'm still hitting this on v0.0.28 (and the code paths look unchanged on current main), so I believe the close was premature — could this be reopened?

The closing comment said a thread waiting for user input is no longer treated as running, but that doesn't match what's in the code:

• The sidebar hides the archive icon whenever the session is running with an active turn — apps/web/src/components/Sidebar.tsx:460:

  const isThreadRunning =
    thread.session?.status === "running" && thread.session.activeTurnId != null;

  and archiveThread in apps/web/src/hooks/useThreadActions.ts rejects with ThreadArchiveBlockedError on the same condition.
• A mid-turn question from the agent produces a user-input.requested activity (which drives the "Awaiting Input" pill via pendingUserInputCount), but in apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts that event only flushes/finalizes the streamed assistant segment — it never emits a thread.session.set that ends the turn or clears activeTurnId. Session status only leaves running on turn.completed, session.exited, or a session state change.
• The provider runtime's "waiting" state is explicitly mapped to "running":

  case "running":
  case "waiting":
    return "running";

  (orchestrationSessionStatusFromRuntimeState in ProviderRuntimeIngestion.ts)

So a thread blocked on an agent question keeps session.status === "running" with a non-null activeTurnId, and the archive action stays hidden — exactly the behavior originally reported. PR #3451 (which is in v0.0.28) only restructured the error type; its description notes there was no change to archive success paths.

Repro on v0.0.28: start a thread, let Claude Code ask a question (thread shows "Awaiting Input"), hover the thread in the sidebar → no archive icon until the question is answered.