On a Linux desktop the app signs in and works (chat, cloud computer, routines), but the computer never connects for local execution: it shows as disconnected in Grok’s device list, so the Bot can’t run commands on it. A Windows desktop on the same account connects and runs commands fine.
Environment
Debian 13 (trixie) x64, XFCE session (lightdm autologin), a Proxmox VM
Grok Bot 0.79.2, official .deb, running as a systemd user unit
Egress only through an HTTP proxy (no direct internet, no DNS on the box). HTTPS_PROXY set, and NODE_USE_ENV_PROXY=1 (without it the Node side ignored the proxy)
The proxy log shows no refusals for Cursor/xAI hosts: api2.cursor.sh, api3.cursor.sh and the *.cursorvm.com pod all tunnel with 200. Only browser telemetry/ads are refused
Already tried
Signing out and back in (each sign-in shows “Unverified device” in the browser; approved)
After sign-in two Node utility processes start and hold proxy connections, but the computer still isn’t usable for local execution.
Questions
Is local execution supported on Linux in 0.79.2? The docs list Linux for the app, but other pages mention only macOS/Windows for local execution.
Does the local-exec connection need a host or protocol beyond api2/api3.cursor.sh and *.cursorvm.com (e.g. something an HTTP CONNECT proxy would break)?
Where does the app log local-exec daemon start/failure on Linux, so I can attach it?
Steps to Reproduce
Install Grok Bot 0.79.2 (.deb) on Debian 13 XFCE behind an HTTP proxy, NODE_USE_ENV_PROXY=1
Sign in
Settings → Computer: the Linux computer is listed but shows disconnected; the Bot can’t run local commands on it
I’m not on the team, so I can’t say for sure whether local execution is supported on Linux in 0.79.2. I couldn’t find a direct confirmation in the docs either way. I do have a couple of thoughts on the other two points.
About the proxy. According to the docs at Configure TLS-inspecting proxies | Cursor Docs, the app talks to *.cursor.sh and to the cloud computer at the nested address *.*.cursorvm.com. That page describes the exact symptom you’re seeing: chat works, but the computer never connects. That usually happens when the proxy allows the first one but breaks the second. It can break it not only by denying it, but also by buffering or dropping long-lived connections. A CONNECT with status 200 doesn’t always mean the tunnel stays alive for more than a couple of minutes. I’d check:
Idle and read timeouts, plus any max lifetime limit for CONNECT tunnels on the proxy. For a persistent connection, these need to be high enough.
That the ACL covers the nested level *.*.cursorvm.com, not just *.cursorvm.com. Some proxies treat a wildcard as exactly one level.
NO_PROXY=localhost,127.0.0.1,::1. With NODE_USE_ENV_PROXY=1 and no NO_PROXY, Node may send even local requests between app processes through the proxy. That would fit the symptom if chat works but local execution does not. Still, that’s just a guess, so it’s worth testing.
Missing DNS. If some part of local execution doesn’t honor the proxy env vars and resolves addresses on its own, it may fail quietly if the machine has no DNS.
The fastest way to narrow it down is to temporarily give the VM direct internet access and DNS. If the computer connects, the issue is likely the proxy or the environment. If it still doesn’t, then it may be something on the Linux build side.
About logs. I don’t know exactly where the app writes logs on Linux. Since you’re running it as a systemd user unit, I’d first check journalctl --user -u <unit-name> -f while signing in. You could also start the app manually from a terminal with the same env vars and watch stdout and stderr. Also try looking for a log directory under ~/.config/, usually inside the app’s folder.
If you get logs or a result from testing without the proxy, share them here. That should make it easier to see what’s going on.
Hi @jnctech, local execution is supported on Linux in 0.79.2, so this isn’t a platform limit.
No extra host is needed beyond api2.cursor.sh. The cursorvm.com hosts (and the tunnel timeout and wildcard tips above) are for the hosted computer, which already works for you. What I suspect is that the connection that keeps your own computer showing as connected goes straight to api2.cursor.sh and ignores HTTPS_PROXY, even with NODE_USE_ENV_PROXY=1. With no direct route or DNS on that VM it never connects, which would also explain why your proxy log looks clean.
The log you want is ~/.grokbot/local-exec-daemon.log. Could you paste a few lines from it that start with [user-computer-provider], like “watch stream failed” or “poll failed”? A DNS or connection error for api2.cursor.sh there would confirm it.
Thanks @Colin, that was it. ~/.grokbot/local-exec-daemon.log showed exactly what you described:
[user-computer-watch] dialing (attempt 1)
[user-computer-provider] watch stream failed: ConnectError (ENOTFOUND)
[user-computer-watch] ended error after 14 ms dialing, cause ENOTFOUND
So the local-exec daemon’s watch stream dials api2.cursor.sh directly and resolves it itself. It ignores HTTPS_PROXY, even with NODE_USE_ENV_PROXY=1 (I also tried SAND_HTTPS_PROXY). The VM deliberately has no DNS and no direct egress, so it failed before reaching the proxy, which is why the proxy log was clean.
Workaround, which keeps the VM proxy-only:
/etc/hosts: 127.0.0.2 api2.cursor.sh
a small systemd service running socat TCP-LISTEN:443,bind=127.0.0.2,fork,reuseaddr PROXY:<proxy>:api2.cursor.sh:443,proxyport=<port>, which tunnels it through the HTTP proxy with CONNECT. TLS is still end-to-end with the real certificate.
After that the log shows connected after 320 ms and the computer shows as connected. Local execution works, and it survives a reboot.
Feature request: could the local-exec daemon honour HTTPS_PROXY/NODE_USE_ENV_PROXY like the rest of the app does? Then locked-down hosts wouldn’t need the tunnel.
Thanks also @andrewbalan, the DNS point (4) was on the money.