Gemini sessions hang

[achatham]

What version of HAPI is running?

0.16.5

What platform is your computer?

Ubuntu, Android pwa client over wireguard

What issue are you seeing?

Every nontrivial session with Gemini eventually hangs, with the blue indicator that suggests it's "thinking", but it never recovers. I've seen the Gemini cli client hang sometimes in similar ways, but this is way more frequent. Every session beyond a few steps hangs this way, whereas I can complete similar take on the CLI without problems.

I'll attempt to look into this more. I haven't figured out how to get a more complete log of what it's doing with grmini-cli, so I can't tell what it's stuck on.

Claude works with the same installation.

What steps can reproduce the bug?

Perform a non trivial task with Gemini cli as the backend.

What is the expected behavior?

Continues with output or ends and waits on the user.

Additional information

No response

[github-actions]

This looks consistent with the Gemini ACP backend getting stuck in a prompt, rather than only a web UI rendering bug.

The main code-path difference vs running Gemini directly in a terminal is that HAPI launches Gemini in ACP mode (gemini --experimental-acp), not the normal interactive CLI path. In the remote Gemini path, HAPI sets the session to thinking=true immediately before backend.prompt(...) and only clears it after that prompt call returns or throws. The ACP backend sends session/prompt with timeoutMs: Infinity, and I did not find a watchdog/recovery path for a prompt that never resolves. So if Gemini ACP stalls mid-turn, HAPI will keep broadcasting thinking=true, and the web app will continue showing the blue thinking state.

I also verified that classified Gemini stderr errors are supposed to be surfaced into the session as visible status messages in this path. If your hang is completely silent, that suggests it may be a stall that never reaches one of those handled error cases.

Relevant code:

• cli/src/gemini/utils/geminiBackend.ts:27 - HAPI starts Gemini with --experimental-acp
• cli/src/gemini/geminiRemoteLauncher.ts:133 - sets Gemini session to thinking before prompt
• cli/src/gemini/geminiRemoteLauncher.ts:148 - clears thinking only after prompt finishes/fails
• cli/src/agent/backends/acp/AcpSdkBackend.ts:167 - sends session/prompt
• cli/src/agent/backends/acp/AcpSdkBackend.ts:170 - prompt timeout is Infinity
• hub/src/sync/sessionCache.ts:179 - hub stores/broadcasts the thinking flag from keepalive
• web/src/lib/assistant-runtime.ts:185 - web runtime treats session.thinking as running state
• cli/src/gemini/geminiRemoteLauncher.ts:63 - Gemini remote path forwards parsed stderr errors into the session
• cli/src/agent/backends/acp/AcpStdioTransport.ts:293 - stderr parsing covers rate limit / auth / quota / model-not-found cases
• cli/README.md:53 - hapi runner logs exists
• docs/guide/installation.md:391 - runner/hub logs live under ~/.hapi/logs

Need more info:

• Was this session started via hapi gemini directly, or via hapi runner remote spawn?
• When it hangs, can you attach the relevant excerpt from the latest HAPI log around that time (hapi runner logs, or the matching file under ~/.hapi/logs)?
• In that log, do you see any of these lines near the stall: [ACP][stderr], ACP process exited, or Gemini prompt failed?
• What does gemini --version report on that machine?

---

HAPI Bot