Sessions hang on "working" when used with Anthropic subscription

[eyalroth]

What happened?

I just started using pi.dev, and I also have a new Anthropic Enterprise subscription.
I noticed that from time to time, my sessions get stuck on "Working...", usually all at the same time.
Interrupt / stop and resume session sometimes work and sometimes not (have to wait more).

It didn't seem to me like an issue with any tool or extension, but rather hang on connectivity issues with Anthropic.
It might be API rate limiting (I don't have enough experience to say if that's the case).

Opus 4.8 tried to debug this and claimed that the issue is that there's no HTTP/stream timeout option for Anthropic SDK.

Steps to reproduce

Honestly not sure, other than using Anthropic.

Expected behavior

I would expect pi.dev to detect connectivity issue faster and either retry or fail loudly.

Version

0.78.0, Node v24.15.0, MacOS 26.5

[github-actions]

This issue was auto-closed. All issues from new contributors are auto-closed by default.

Maintainers review auto-closed issues daily and reopen worthwhile ones. Issues that do not meet the quality bar in CONTRIBUTING.md will not be reopened or receive a reply.

If a maintainer replies lgtmi on one of your issues, your future issues will stay open. If a maintainer replies lgtm, your future issues and PRs will stay open.

See CONTRIBUTING.md.

[badlogic]

without a repro, it's going to be hard to fix this, i'm afraid :(

[SeanMcLoughlin]

FWIW I too am experiencing this. It seems like something is wrong with authentication because it happens exactly every 30 minutes for me, at the :00 and :30 minute marks.

I too kill it when it's stuck "Working..." and after trying that a few times, a few minutes after the half-hour mark, it starts working again.

I tried getting pi to write an extension to force a re-authentication every 20 minutes or so but it didn't seem to help.

You might be able to reproduce it by having an agent run a long running task that crosses a 30-minute-mark boundary.

Let me know if you want a new issue filed or to have this one re-opened. This is becoming a major blocker for me because I can't depend on pi to do long-running tasks for me anymore.

[eyalroth]

I'll point out that I noticed this happening with AWS Bedrock as well.

I've currently created a patch (100% vibe coded with Opus) to my local pi.dev.
If this proves useful, I'll consider opening an actual PR to the repo.

[okhick]

Can confirm this is also happening to me using my company's Anthropic Enterprise subscription. Also can confirm that I'm hit on the :00 and :30 minute marks.

[shawnpark07]

Hi, I'm experiencing very similar problem.
Have you opened the PR?

[eyalroth]

Opened PR: #6051

With these changes, I get a much better mitigation of the connectivity issues. I also get visible errors in the chat/UI that let me know something is wrong and I'm not hallucination 😅

[eyalroth]

@badlogic I've been able to reliably reproduce this (see below) + heavily debugged the issue (including tcp dumps) and found the cause.

The hangs are triggered by pi's default system prompt.
With everything else identical, a minimal (two words) system prompt doesn't hang.

Not only that I reproduced it many times throughout the day, but I isolated specific parts of the prompt that trigger this behavior.
I'm currently running with a modified system prompt and experiencing no hangs so far (I'm optimistic).

I'd rather not share the modified system prompt publicly, because it could be used to target pi again.

---

Rough reproduction script:

  run() {  # $1=label, rest=extra args
    local label="$1"; shift; local t0=$(date +%s)
    timeout 90 pi -p "hi" --model claude-haiku-4-5 \
      --no-tools --no-context-files --no-skills --no-extensions "$@" >/dev/null 2>&1
    echo "$(date -u +%H:%M:%S) $label $(( $(date +%s) - t0 ))s"
  }
  while true; do
    run DEFAULT &                             # pi's stock system prompt
    run MINIMAL --system-prompt "Be brief." & # minimal replacement
    wait; sleep 10
  done

Run it a few minute before and after :00/:30 UTC (i used :57/:27 -> :02/:32).
"healthy" call should be just a few seconds, while a "hanging" one should take much much longer.