google-gemini-cli TUI hangs 3min — agent command works fine

[late glade]

I'm running OpenClaw on WSL2 Ubuntu (Windows 11),
gateway started manually. Everything authenticates
fine but the TUI never actually responds.

Setup:

• OpenClaw 2026.4.12 (1c0672b)
• Node 24.14.1 via nvm
• Primary model:
  google-gemini-cli/gemini-3.1-pro-preview
• Gateway: local, port 18789
• Channel: Telegram

What works:

• openclaw agent --agent main -m "pong" → returns
  "pong" in ~12s ✓
• gemini -m gemini-3.1-pro-preview -p "pong" directly
  → works in ~15s ✓
• Telegram responds sometimes, but inconsistently

What doesn't work:

• TUI: on every connect, immediately shows Agent
  failed before reply: No API key found for provider
  "google" — before I type anything
• If I type a message anyway, it spins for 3 minutes
  then watchdog kills it (noOutputTimeoutMs=180000)
• gemini -m gemini-3-flash-preview -p "pong" → runs
  15s, zero output

4 diagnostic commands:
openclaw --version → OpenClaw 2026.4.12
(1c0672b)
which gemini →
/home/ricardo/.nvm/versions/node/v24.14.1/bin/gemini
gemini --version → 0.38.0
models status → auth ok, expires in 24m,
Pro 100% / Flash 100% left

What I've already tried from the FAQ:

• openclaw plugins enable google ✓
• Pinned absolute path in cliBackends.command ✓
• Renewed OAuth token ✓
• GOOGLE_CLOUD_PROJECT — not set (personal Gmail, no
  GCP project — do I need this?)

My questions:

1. Why does openclaw agent --agent main work but TUI
   hangs? Is there a different code path?
2. The boot error (No API key for provider "google")
   fires before I type anything — what's triggering
   that?
3. gemini-3-flash-preview produces no output from CLI
   directly — is that a known issue with gemini 0.38.0?

[candid crescent]

I dug through the source, and yes, this looks like two different paths.

1. Why openclaw agent --agent main -m "pong" works but TUI hangs

• The TUI attaches to an existing gateway session and uses chat.send / chat.history.
• For Gemini CLI, the bundled backend is configured with:
  • sessionMode: "existing"
  • resumeArgs: ["--resume", "{sessionId}", ...]
  • file: extensions/google/cli-backend.ts
• So TUI is exercising the resume path, not just a fresh one-shot invoke.

Your direct checks only prove this works:

• fresh OpenClaw agent run
• fresh gemini -m gemini-3.1-pro-preview -p "pong"

They do not prove that:

• Gemini CLI resume mode works
• Flash works

• the current TUI session is using Pro instead of an older Flash/default session

2. What triggers the boot error before you type

• On connect, TUI does refreshAgents() and then loadHistory() immediately, before sending any new prompt.
• loadHistory() just replays stored session messages into the chat log.
• The exact banner text ⚠️ Agent failed before reply: ... is generated by src/auto-reply/reply/agent-runner-execution.ts.

So that startup error is very likely an old failure being replayed from session history, not a fresh auth check caused by connecting the TUI.

3. Why the 3 minute hang matches your symptoms

• Gemini CLI resume watchdog defaults are 60s..180s
• file: src/agents/cli-watchdog-defaults.ts
• the runner kills the process when it produces no output for that window

That lines up exactly with your noOutputTimeoutMs=180000.

4. About gemini-3-flash-preview returning zero output

• I did not find a documented OpenClaw note saying “Gemini CLI 0.38.0 Flash is broken”.
• But your repro is pretty strong: gemini-3.1-pro-preview prints output, gemini-3-flash-preview returns nothing.
• That makes Flash the most likely culprit for the TUI stalls.

My best read is:

• your current TUI session is probably resuming a session/path that lands on Flash
• Flash is emitting zero stdout
• OpenClaw waits, then watchdog kills it

5. Do you need GOOGLE_CLOUD_PROJECT?

• Not for the basic “personal Gmail + Gemini CLI OAuth” path if requests already work.
• Docs only say to try GOOGLE_CLOUD_PROJECT / GOOGLE_CLOUD_PROJECT_ID if Gemini CLI OAuth requests fail after login on the gateway host.
• Since Pro already works for you, I would not treat that as the root cause.

What I’d try next

• Start a brand new session in TUI instead of resuming the current one.
• Make sure no session/default/fallback is still pinned to google-gemini-cli/gemini-3-flash-preview.

• If possible, force everything to google-gemini-cli/gemini-3.1-pro-preview for now.

Docs:

• https://docs.openclaw.ai/help/faq
• https://docs.openclaw.ai/providers/google

If you want, paste one openclaw logs --follow snippet from a single TUI send, and I can help pinpoint where it’s still choosing Flash or google.

[late glade]

Thanks — here's the log. The model IS Pro in the
second gateway restart,
but it still times out. Looks like it works on
message 1 but hangs on message 2.

00:37:09 cli session reset reason=mcp
00:37:09 cli exec model=gemini-3.1-pro-preview
promptChars=237 ← worked
00:49:54 cli exec model=gemini-3.1-pro-preview
promptChars=216 ← worked
00:50:30 cli exec model=gemini-3.1-pro-preview
promptChars=204 ← hung 180s
00:53:24 watchdog timeout — "CLI produced no output
for 180s and was terminated"

Pattern: first exec after a session reset works,
second exec in the same session hangs.
This matches what the user sees: 2 quick replies,
then stuck.

Note: the previous gateway instance (before my
restart) was running Flash —
that may have left a corrupted session in the resume
path.

Questions:

1. Is there a way to configure sessionMode to "fresh"
   per-invoke instead of "existing"?
   (so it doesn't try to resume a subprocess that may
   have exited after the first response)
2. Is the gemini CLI subprocess expected to stay
   alive between messages?
   Or should OpenClaw be restarting it each time?
3. The reason=mcp reset before sessions — what
   triggers this and can it be reduced?

[candid crescent]

Nice catch, that log helps a lot.

Short version: this now looks like a Gemini CLI resume bug/quirk, not a “wrong model” issue.

1. Can you force “fresh” instead of “existing”?
   Yes, but not as a per-message automatic toggle.

From the config/docs, the only sessionMode values are:

• always
• existing
• none

There is no built-in "fresh" mode. The closest workaround is:

{
  agents: {
    defaults: {
      cliBackends: {
        "google-gemini-cli": {
          sessionMode: "none",
        },
      },
    },
  },
}

That disables CLI session reuse entirely, so OpenClaw stops sending --resume {sessionId}.

For your case, I think that’s the right test.

2. Is the Gemini CLI subprocess supposed to stay alive between messages?
   No.

OpenClaw spawns a new child process per turn, waits for it to exit, parses stdout, and stores the returned session id for later reuse. So continuity is via session id, not via a long-lived subprocess.

So if message 1 works and message 2 hangs only when resumed, that strongly suggests the problem is in the Gemini CLI resume path, not that OpenClaw forgot to keep the process alive.

3. What does reason=mcp mean?
   That comes from stored CLI session reuse being invalidated because the generated MCP config hash changed.

The exact invalidation reasons are:

• auth-profile
• auth-epoch
• system-prompt
• mcp

For Gemini CLI, bundleMcp: true is enabled, so OpenClaw generates Gemini system settings / MCP config and hashes it. If that config changes, the old CLI session is discarded and a fresh one is started.

Common triggers:

• gateway restart with a different loopback MCP port
• changed enabled MCP servers/tools
• changed MCP-related config

Importantly, in your log the reason=mcp reset happens before the working run, so I don’t think it’s the cause of the later hang. The hang is happening on the second resume in the same session, without another reset in between.

So my current read is:

• fresh run after reset: works
• resumed Gemini CLI session: hangs on later turn
• watchdog kills it after 180s

That points pretty directly at Gemini CLI --resume.

What I’d try next

1. Set google-gemini-cli.sessionMode: "none"