grok: repeated 'ask' calls create separate conversations instead of continuing the same thread

[marie6789040106650]

Summary

opencli grok ask appears to create a new Grok conversation on every invocation, even when --new is not passed. This makes it hard to use the Grok adapter for true multi-turn conversations.

Environment

• opencli version: 1.3.3
• Browser Bridge extension: installed and connected
• opencli doctor: all green
• Browser: real Chrome session with Grok login reused successfully

What works

• opencli doctor reports daemon / extension / connectivity are healthy.
• opencli grok ask "..." can successfully send a prompt and receive a response.
• Grok can access live X/Twitter content through the adapter.

Problem

Although repeated opencli grok ask calls succeed, each call seems to land as a separate conversation in the Grok web UI, instead of continuing the same chat thread.

That means the current Grok adapter behaves more like a single-shot query interface than a persistent chat session.

Reproduction

1. Run:

   opencli grok ask "First question" --new true

2. Then run:

   opencli grok ask "Second question that depends on the previous answer"

   (without --new true)
3. Check the Grok web UI history.

Actual behavior

• The second prompt appears as a new/independent conversation in the Grok UI.
• There is no reliable session continuity.
• This makes multi-turn workflows brittle, because callers must manually restate context every time.

Expected behavior

One of these should be true:

1. Session continuity by default: if --new is not passed, continue the currently active Grok conversation.
2. Explicit session controls: expose commands/options like new, read, history, resume, status, or a session/thread id.
3. Document current behavior clearly: if Grok is intentionally single-shot, the docs/help should say so explicitly.

Why this matters

Other adapters can be used as part of longer-running agent workflows. For Grok, users may reasonably expect:

• ask once to start a thread
• ask again to continue that thread
• inspect/read the current thread

Right now, the Grok integration is great for one-off queries, but not reliable for persistent multi-turn dialogue.

Suggestion

A minimal fix would be:

• keep using ask, but make it reuse the current active Grok thread unless --new true is passed.

A better long-term API might be:

• opencli grok new
• opencli grok ask <prompt>
• opencli grok read
• opencli grok history
• opencli grok status

Thanks — the real-Chrome session reuse is excellent, this is just the main missing piece for conversational workflows.

[Astro-Han]

Root cause identified — the adapter unconditionally navigates to https://grok.com/ (the new-chat page) on every invocation, even when --new is not passed.

In runDefaultAsk (ask.ts:75):

// This runs regardless of newChat — always resets to homepage
await page.goto(GROK_URL);

Same issue in runExplicitWebAsk (ask.ts:252).

The browser daemon already reuses the same Chrome tab across commands for the same site, so the previous conversation URL (e.g. grok.com/chat/abc123) is preserved between calls. The unconditional goto() destroys that state.

Minimal fix: only navigate to grok.com/ when newChat=true; otherwise skip navigation and let the tab stay on the existing conversation. Edge case: detect if the tab is on a blank page (first run or after idle timeout) and navigate to grok.com/ in that case.

Additionally, the if (newChat) block at lines 62-73 in runDefaultAsk is effectively dead code — it navigates and clicks "New", but line 75 immediately navigates to the homepage again, overwriting whatever it did.