Skip to content

Crash when deleting Claude threads: "All fibers interrupted without error" #1273

Closed
#1365
Closed
Crash when deleting Claude threads: "All fibers interrupted without error"#1273
#1365

Description

@atduarte
atduarte
opened on Mar 21, 2026

Description

Deleting threads in t3code frequently results in a crash with the following error:

file:///.npm/_npx/5ca66e5ae19a7ff4/node_modules/effect/dist/internal/effect.js:171
 return new globalThis.Error("All fibers interrupted without error");
        ^

Error: All fibers interrupted without error
    at Module.causeSquash (effect/dist/internal/effect.js:171:12)
    at Object.next (effect/dist/Stream.js:6879:21)
    at async h4.streamInput (@anthropic-ai/claude-agent-sdk/sdk.mjs:22:1905)

Steps to Reproduce

  1. Open t3code
  2. Have an existing Claude thread
  3. Delete the thread
  4. Application crashes with the above error

Additional Context

  • The error originates from the Effect library's fiber interruption handling, surfacing through @anthropic-ai/claude-agent-sdk.
  • Sometimes the deletion hangs before eventually completing, other times it crashes immediately.
  • Multiple users have independently confirmed this behavior.

Activity

  1. atduarte
    changed the title [-]Crash when deleting threads: "All fibers interrupted without error"[/-] [+]Crash when deleting Claude threads: "All fibers interrupted without error"[/+] on Mar 21, 2026

  2. juliusmarminge commented on Mar 21, 2026

    @juliusmarminge
    juliusmarminge
    on Mar 21, 2026
    Member

    Will look into this, i fixed this crash in another place.

    Tldr the agents SDK sucks and it's interuption model is rough... wanted to use the new v2 which seems much more intuitive but it didn't have enough features yet :/

  3. keyzou commented on Mar 24, 2026

    @keyzou
    keyzou
    on Mar 24, 2026
    Contributor

    Was looking at this today, this happens when there's been an active session on a thread. Looks like that comes from the fact when we're shutting down the message queue, the cancellation is passed to the SDK loop and since it's a thrown "error", it raises. It can also happen when shutting down the app I'm guessing.

    Not sure if that's going to fix every case, but shouldn't we get away with adding a catchCause before transforming the message stream to an async iterable so that we catch the cancellation and exit properly ?

    Something along the lines of:

    Stream.catchCause((cause) =>
  Cause.hasInterruptsOnly(cause) ? Stream.empty : Stream.failCause(cause),
),

    This way we still let actual errors through but properly handle interruptions.

    I've been running this locally for a while and haven't got any issue since.

    What do you think Julius ? I'll create a PR in the meantime, feel free to close it if I'm mistaken :)

  4. juliusmarminge
    closed this as completedin #1365on Mar 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions