Closed general

grok_open launches nothing but reports success; grok_chat_read only sees the focused thread; runUuid not surfaced

John Lauer · 1mo ago ·closed by John Lauer

Bugs hit driving grok-bridge from a container (2026-08-31, AdomLapper, grok-bridge 1.2.2)

Filed per John: every issue an AI hits with grok-bridge goes to grok-bridge so it can fix itself.

  1. grok_open reports success but never starts the app. It returned success:true ("Asked ab desktop_open to start Grok Bot in the BACKGROUND") and for 60+ s there was no Grok Bot process at all (Get-Process empty, desktop_find_window titleContains Grok empty, exe present at C:\Users\john\AppData\Local\Programs\Grok Bot\Grok Bot.exe). Starting the exe directly with Start-Process -WindowStyle Minimized worked immediately (10 processes, window titled "Grok Bot"). Fix: after the background launch, poll for the process/window and return launched:true|false with a real error; fall back to a direct Start-Process (minimized, no focus) when desktop_open doesn't take.
  2. grok_open's success envelope carries no state — hwnd, opened, alreadyOpen all null. A caller can't tell "launched" from "already up" from "did nothing." Populate them.
  3. grok_chat_read reads only the focused thread, so after a cold launch it returned an empty transcript, then just the focused thread's tiny Document ("Resize details / grok-bridge is working", 40 chars). Webhook replies land in the grok-bridge thread, but there's no way to target it. Fix: a thread/agent selector (locate that thread's Document by name), or auto-focus grok-bridge when reading; and return focusedThread so callers know what they read.
  4. grok_webhook_fire returned runUuid: null on a successful HTTP 200 — the skill documents the 200 body as {runUuid}; it's not being surfaced, so there's no handle to correlate a fired event with its run. Surface it, and ideally add grok_run_status {runUuid} so a caller can poll a specific event instead of grepping the transcript for a nonce.
  5. Low-confidence: adom-bridge commands | grep grok_ matched nothing while the grok bridge was listed running (1.2.2) — verbs may not be in the commands listing in the expected grok_* form. Worth a check.

Repro context: container → ab relay → AdomLapper; Grok Bot cold (not running) at the start. Items 1–3 cost ~5 minutes of diagnosis each time a container session needs Grok Bot up; 1 and 3 are the ones that block hands-off use.

1 Reply

John Lauer · 5d ago

All five items are fixed (1.2.x to 1.3.3):

  1. grok_open polls for the process/window after the background launch and falls back to Start-Process -WindowStyle Minimized; it returns launched: true|false with a real error.
  2. The envelope fills hwnd, opened, alreadyOpen and launched.
  3. grok_chat_read {thread|agent} selects that sidebar row, and with no selector auto-tries grok-bridge after a cold start; every read returns focusedThread. As of 1.3.3 it is never a caption-button name (see #5).
  4. grok_webhook_fire surfaces runUuid at the top level, and grok_run_status {runUuid} echoes the last fire.
  5. adom-bridge commands lists all 33 grok_* verbs (checked today).

Log in to reply.