You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Windows: "Could not find a Grok Bot agents directory" after the Oct 5 Grok Bot app update (gateway-descriptor.json no longer written) #147
grok-bot-cli 0.12.4 (also reproduces on 0.9.0), installed from npm, run with Node 22.23
Windows 11 Pro, Grok Bot desktop app updated on 2026-10-05 (app binary dated 10/5)
What happens gbot bots list (and thread/send) fail with:
render-failed: Could not find a Grok Bot agents directory. Pass --dir or set GROK_BOT_AGENTS_DIR.
This worked until the app update on 10/5.
What we found (file and key names only, no secret values read)
%APPDATA%\Grok Bot\gateway-descriptor.json no longer exists after the app update, so hasGrokBotGatewaySession returns false and the CLI falls back to files mode.
%USERPROFILE%\.grokbot\agent-data does not exist on Windows either, so files mode finds no roster.
Ask
Could the CLI locate the live gateway session from wherever the updated Windows app keeps it now? Happy to run a diagnostic command and report file/key names (never values) if that helps.
Thanks for the tool — it's been the backbone of our agent-to-agent link.
Same on macOS (Grok Bot 0.68.1, grok-bot-cli 0.12.4) since the early-October app update: gbot doctor shows gateway auth: no / Grok Bot app session: not found, and send fails with Could not find a Grok Bot agents directory. desktop-status.json still says signedIn: true, and the "Grok Bot Safe Storage" keychain item is present.
Cause. We read the app bundle for file and key names only, no secret values. The descriptor store is still there, but since the cloud-computer "park" mode it is only written when the box was already running when the app connected:
The route store gets mayStoreRoute: () => isKeptAsleepByBackend() !== true.
isKeptAsleepByBackend turns true the first time locate() finds the box not running (hibernated or absent). After that, the app wakes the box with connect(). The flag is only reset when the account scope changes.
While the flag is true, every successful connect calls store.remove(scope) instead of store.write(scope, connection). remove deletes gateway-descriptor.json once no entries are left.
So once the box has been asleep at least once during an app session, the descriptor disappears and stays gone until the app restarts. The CLI then falls back to files mode, which gives the "agents directory" error above.
Workaround that worked here. Quit and relaunch the app while the cloud computer is awake, e.g. while an agent is working or right after you send it a message. The descriptor came back 2 s after launch, gbot doctor reported Grok Bot app session: usable, and gbot send went through.
osascript -e 'tell application "Grok Bot" to quit'&& open -a "Grok Bot"
On Windows the equivalent is quitting from the tray and relaunching. I'd expect the same mechanism there, but I've only verified macOS.
Suggestions.
The real fix is in the app: keep the route, or write it again on the next live connection, instead of removing it while the box is parked.
On the CLI side, gbot doctor could detect a running, signed-in app with no descriptor and print this restart hint instead of the files-mode error.
Activity
gvitolocs commentedon Oct 10, 2026
Same on macOS (Grok Bot 0.68.1, grok-bot-cli 0.12.4) since the early-October app update:
gbot doctorshowsgateway auth: no/Grok Bot app session: not found, andsendfails withCould not find a Grok Bot agents directory.desktop-status.jsonstill sayssignedIn: true, and the "Grok Bot Safe Storage" keychain item is present.Cause. We read the app bundle for file and key names only, no secret values. The descriptor store is still there, but since the cloud-computer "park" mode it is only written when the box was already running when the app connected:
mayStoreRoute: () => isKeptAsleepByBackend() !== true.isKeptAsleepByBackendturns true the first timelocate()finds the box not running (hibernated or absent). After that, the app wakes the box withconnect(). The flag is only reset when the account scope changes.store.remove(scope)instead ofstore.write(scope, connection).removedeletesgateway-descriptor.jsononce no entries are left.So once the box has been asleep at least once during an app session, the descriptor disappears and stays gone until the app restarts. The CLI then falls back to files mode, which gives the "agents directory" error above.
Workaround that worked here. Quit and relaunch the app while the cloud computer is awake, e.g. while an agent is working or right after you send it a message. The descriptor came back 2 s after launch,
gbot doctorreportedGrok Bot app session: usable, andgbot sendwent through.On Windows the equivalent is quitting from the tray and relaunching. I'd expect the same mechanism there, but I've only verified macOS.
Suggestions.
gbot doctorcould detect a running, signed-in app with no descriptor and print this restart hint instead of the files-mode error.2689508458 commentedon Oct 11, 2026
补充 Windows 实测:上面“云电脑唤醒期间彻底退出并重开桌面端”的恢复方法,已在本机原生 Windows / Grok Bot 0.68.1 上验证有效。
具体步骤:打开任意 Bot 的 Computer 页面并等待云电脑连接,从系统托盘彻底退出 Grok Bot,然后在云电脑仍唤醒时立即重新打开。仅打开 Computer 页面时连接文件仍然缺失,完整重启后
gateway-descriptor.json才生成。还需要留意第二个问题:新生成的文件使用版本 3,未打补丁的 grok-bot-cli 0.12.4 报
Unsupported Grok Bot gateway descriptor version 3.。本地应用 #143 的兼容修改后,gbot doctor的会话可用性检查通过,gbot bots list --json成功返回云端列表。详细验证已补充到 #143。这确认的是上述恢复步骤和 v3 兼容修改共同恢复了本机 CLI 连接;没有验证该步骤能永久避免休眠后的文件再次消失。没有采用 #145 的凭据回退,也没有发送 Bot 任务。建议 doctor 在“桌面端运行且已登录,但连接文件缺失”时给出这个恢复提示。