Desktop and Browser Automation Not Working

Support Help
1

image
image1920×1202 80.8 KB
I’m experiencing a problem with Grok Bot’s desktop and browser automation. Shell commands and file operations work normally, and all 11 computer health checks pass, including the browser, display, network connection, and D-Bus.

However, tasks that require desktop or browser control fail without producing any result. The desktop view remains on an empty wallpaper, and the browser does not open the requested webpage. This suggests that the issue is specifically with the desktop/browser automation service rather than the computer itself.

Could you please investigate the desktop control service for my Grok Bot computer? I have attached a screenshot of the computer status. If you need any additional logs or diagnostic information, please let me know.

Thank you for your help.

Best regards,
Davie

5

Hi,

Thanks for posting on the Cursor forum!

To help ensure most of our users can participate in discussions, this forum is currently English only.

If you’d like, you can edit your post to translate it into English. Once it meets our guidelines, it will be automatically relisted.

Thanks for understanding!

Note: This is an automated detection system and sometimes makes mistakes. If your post is already in English, feel free to ignore this message, or just make a small edit and it will be reviewed again.

9

Please help me resolve this issue as soon as possible, as it is preventing me from completing my work.

10

same，please recover quickly

11

same here, problem happened since 5am GMT +8, more than 8 hrs now

12

Same here

13

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Content:
My Grok Bot desktop control service is failing.
Symptoms:
• Asking any Bot to perform browser or desktop actions fails
• Error is failed_precondition
• Screen view only shows an empty Windows desktop with no applications open
• Tasks are accepted but finish almost immediately, with no screenshot and no detailed error report
• Shell commands and file operations work normally; only desktop / browser control is broken
Already tried:
• Fully quit and reopened Grok Bot
• Reset Bot’s Computer (already done)
• Issue remains the same
Time:
Started approximately today (or recently)
Impact:
All tasks that require a browser cannot be completed
Please help check the status of the desktop agent layer (computerUse / exec-daemon). Thank you.

Steps to Reproduce

  1. Open Grok Bot desktop app
  2. Open any existing Bot
  3. Ask the Bot to open a website in the browser or perform any desktop/browser action (e.g. “Open google.com” or “Take a screenshot”)
  4. Observe: the task is accepted but finishes almost immediately with failed_precondition
  5. Open the Bot’s Screen view → it only shows an empty Windows desktop with no applications open
  6. Shell commands and file operations still work normally

Expected Behavior

The Bot should be able to open the browser, navigate to websites, take screenshots, and perform desktop actions normally. The Screen view should show the actual desktop with applications running when tasks are in progress.

Screenshots / Screen Recordings

IMG_4625.jpeg
IMG_4625.jpeg1320×827 56.5 KB

Operating System

iOS

Version Information

Grok Bot 1.24.1 (29176)

For AI issues: which model did you use?

Not applicable (desktop/browser control issue)

For AI issues: add Request ID with privacy disabled

Not available

Additional Information

Symptoms match these existing threads:

Shell and file operations work normally.
Only desktop/browser control fails with failed_precondition.
Screen view shows empty Windows desktop.
Already tried full quit + Reset Bot’s Computer — issue remains.
Please clear stuck screen reservation or restore from latest backup (without another Reset).

Does this stop you from using Cursor

No - Cursor works, but with this issue

16

I hit a 403 error on the domain, but the method below sorted it out. You can try it too.

Cloud egress 403 — solution

Symptom. On the cloud box, using the cloud egress proxy (127.0.0.1:8791) to visit any hostname returned:

HTTP/1.1 403 Forbidden
Proxy-Status: sand-egress-tunnel; error=destination_not_found; details="destination resolves to an address on this machine"

Plain HTTPS without that proxy often still worked. Adding 8.8.8.8 to /etc/resolv.conf did not fix it.

Root cause. UDP DNS (including queries to 8.8.8.8:53) is intercepted and every name resolves to 198.18.0.1, an address on the box itself. The egress proxy then refuses the CONNECT, because the destination looks local. DNS-over-HTTPS is not intercepted and returns real public IPs (for example example.com → 104.20.23.154 / 172.66.147.243).

Fix. Run a local DoH stub on 127.0.0.1:53 and point system DNS at it.

  1. Install /usr/local/sbin/doh-resolver.py (UDP listener on 127.0.0.1:53). It answers A/AAAA via https://1.1.1.1/dns-query, with fallback to https://8.8.8.8/resolve. It must return the CNAME chain plus final A/AAAA records (needed for names like www.baidu.com). Drop answers in 198.18.0.0/15.
  2. Start it (needs root to bind port 53):
sudo python3 /usr/local/sbin/doh-resolver.py
  1. Set /etc/resolv.conf to:
nameserver 127.0.0.1
nameserver 8.8.8.8
nameserver 10.0.0.2

127.0.0.1 must be first. The other two are fallbacks only; UDP to them is still intercepted.

  1. Check: getent hosts www.baidu.com should show public IPs, not 198.18.0.1. Then:
curl -I --max-time 20 -x http://127.0.0.1:8791 https://example.com
curl -I --max-time 20 -x http://127.0.0.1:8791 https://www.baidu.com
curl -I --max-time 20 -x http://127.0.0.1:8791 https://weibo.com

Verified after the fix. Baidu homepage 200 (“百度一下，你就知道”). Weibo weibo.com / www.weibo.com / weibo.cn 200 (unauthenticated traffic lands on “Sina Visitor System”, which is Weibo’s own visitor page, not a 403). GitHub, Bilibili, and Taobao also 200 through the proxy. One Weibo-via-proxy attempt hit a transient TLS EOF; three immediate retries succeeded.

Notes. There is no systemd on this box, so the stub is a long-running process; after a reboot, start it again and rewrite resolv.conf. --dns-servers 8.8.8.8 on curl cannot bypass the UDP intercept; use DoH (--doh-url) or this stub. If you want traffic to egress through your own network instead of the cloud path, keep the Grok Bot desktop app online on your machine (it was offline during these tests).

20

Hi all, thanks for flagging this! I’ve shared it with the team, since it appears to affect a few users right now.

22

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Since ~2026-11-06 morning Asia/Shanghai, every computerUse / desktop / browser task on my shared Bot computer is accepted then finishes in a few seconds with failed_precondition / 0 transcript. Parent read-only Screenshot and Shell still work. Desktop looks empty/fine; box-doctor previously PASS.

This matches today’s threads (instant exit / failed_precondition / stuck screen reservation), e.g. 177456, 177458, 177490.

Already tried (all failed):

  • Update Bot’s Computer ×2 (now “already latest”)
  • Full quit + reopen
  • Clear /tmp/sand-window-used.d/*.inflight
  • Brand-new temp bot — same instant exit
  • Have NOT Reset (want bots/files/logins kept)

Support email ticket: T-J39513 — only got AI reply saying it cannot clear reservation / restore backup. Please escalate and refresh my computer from the latest backup WITHOUT Reset (as staff did in 175786).

Steps to Reproduce

  1. Ask any bot to open a site or take a desktop action via computerUse
  2. Task accepted → finishes in seconds → failed_precondition / 0 transcript
  3. Parent Screenshot/Shell still OK

Expected Behavior

computerUse works again after server-side backup restore / clear stuck screen lease. Keep all bots, files, logins.

Additional Information

Account: [email protected]
Timezone: Asia/Shanghai
Please do NOT ask me to Reset.

Steps to Reproduce

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Since ~2026-11-06 morning Asia/Shanghai, every computerUse / desktop / browser task on my shared Bot computer is accepted then finishes in a few seconds with failed_precondition / 0 transcript. Parent read-only Screenshot and Shell still work. Desktop looks empty/fine; box-doctor previously PASS.

This matches today’s threads (instant exit / failed_precondition / stuck screen reservation), e.g. 177456, 177458, 177490.

Already tried (all failed):

  • Update Bot’s Computer ×2 (now “already latest”)
  • Full quit + reopen
  • Clear /tmp/sand-window-used.d/*.inflight
  • Brand-new temp bot — same instant exit
  • Have NOT Reset (want bots/files/logins kept)

Support email ticket: T-J39513 — only got AI reply saying it cannot clear reservation / restore backup. Please escalate and refresh my computer from the latest backup WITHOUT Reset (as staff did in 175786).

Steps to Reproduce

  1. Ask any bot to open a site or take a desktop action via computerUse
  2. Task accepted → finishes in seconds → failed_precondition / 0 transcript
  3. Parent Screenshot/Shell still OK

Expected Behavior

computerUse works again after server-side backup restore / clear stuck screen lease. Keep all bots, files, logins.

Additional Information

Account: [email protected]
Timezone: Asia/Shanghai
Please do NOT ask me to Reset.

Operating System

Linux

Version Information

grokbot0.79.2

Does this stop you from using Cursor

No - Cursor works, but with this issue

25

This issue should be resolved now.