Grok Bot
Public Made by Adomby adom
Grok Bridge lets Adom talk to Grok Bot. Adom's AI environment is for electrical engineers: any provider, any desktop power tool, one place.
grok-bridge has no way to install its own host app: host_app_not_installed is a dead end, and guessing installs the wrong software
The gap
grok_readiness returning host_app_not_installed is a dead end today. The skill and the detect docstring both say "Never tell the user to download the host app themselves" and point at grok_open — but grok_open only detects-and-launches an app that is already on disk. Nothing in the bridge knows where Grok Bot comes from.
I hit this on a fresh machine (ConfRoomROG, Windows). I read grok_detect.py, install.sh, CLAUDE.md, bridge.json, and all seven skill files: there is no installer URL, no winget id, no release asset, no documented download source anywhere in the package. So the agent is told not to punt to the user, and also given no way to proceed. Those two instructions contradict each other.
Worse, guessing is actively dangerous. winget search grok on a clean box returns two plausible-looking wrong answers:
xAI.GrokBuild— official xAI, but it is the coding CLI/TUI (portable exe from x.ai/cli). No GUI, no bots/channels. Would never satisfy detection.RongleCat.GrokApp— installs asGrok, and its own description says "not an official xAI product". Third-party Tauri wrapper.
An agent that guesses either one installs the wrong software on a user's machine and detection still fails.
What the answer actually is
For the record, so the next agent does not have to re-derive it. Grok Bot is distributed through Cursor's infra (which is why the sign-in button reads Sign In with Cursor):
- Downloads page:
https://x.ai/bot— note it 403s any scripted fetch (Invoke-WebRequest, WebFetch). It needs a real browser; I had to drive system Chrome via pup to read the links off it. - Windows x64 installer:
https://api2.cursor.sh/updates/download/stable/win32-x64/grok-bot-cf55d121b6d17368 - ~110 MB, NSIS, silent install with
/S, no admin/UAC needed (per-user). - Authenticode: Valid,
CN="Anysphere, Inc.", O="Anysphere, Inc.", L=San Francisco, S=California, C=US - Lands at exactly the path detect already expects:
C:\Users\<user>\AppData\Local\Programs\Grok Bot\Grok Bot.exe - Version installed: Grok Bot 0.43.0 (Electron 42.1.0)
After that, grok_readiness goes ready: true and grok_open brings up the window at the Sign in screen, which is the correct human handoff.
Ask
Add a grok_install verb (and let grok_readiness/grok_open offer it by name in _next when errorCode: host_app_not_installed).
Suggested shape, consistent with the rest of the bridge:
grok_install {reason}—reasonrequired, same gate asgrok_record_start.- Resolve the per-arch URL rather than hardcoding: x.ai/bot exposes win32-x64 and an Arm64 build; macOS and Linux need their own.
- Verify the Authenticode signer is
Anysphere, Inc.before executing. An install verb that runs an unverified downloaded exe is a worse footgun than the current dead end. - Install silently, then re-run detection and return the same
ready/pathsshape so the caller can just continue. - Never auto-run it. Offer it; the human says yes.
If a verb is too much, the minimum fix is putting the download source in grok_detect.py + SKILL.md so the host_app_not_installed hint can name it. Right now the one thing the agent needs is the one thing the package does not contain.
Also worth a look
grok_open timed out at 30s on first launch (status: timeout, error: "Request timed out") — but the app had in fact started fine; grok_list_windows showed the process and window, and readiness went green ~30s later. Cold Electron first-run exceeds the 30s budget. The _timeoutHint does say not to treat a timeout as failure, and that guidance was correct here, but a first-run launch reporting timeout on the happy path is misleading. Possibly the same root cause as #1.