#Can't use clawd browser

1 messages · Page 1 of 1 (latest)

left micaBOT
#

Based on the docs and your output, here's what's happening and how to fix it:

The Issue

  1. clawdbot browser serve started successfully on port 18791 (the control server is running)
  2. clawdbot browser --browser-profile clawd start is trying to reach the control server through the Gateway, not directly
  3. The error message says: "Start (or restart) the Clawdbot gateway" — this is the key clue 🦐

The browser start command communicates via the Gateway. If the Gateway isn't running (or the browser config isn't in clawdbot.json), it can't reach the control server.

Fix Steps

1. Make sure the Gateway is running

clawdbot gateway status
#

If it's not running, start it:

clawdbot gateway start

2. Add the browser config to your clawdbot.json

Your clawdbot browser serve output already told you what to paste:

{
  "browser": {
    "enabled": true,
    "controlUrl": "http://127.0.0.1:18791"
  }
}
#

Add this to ~/.clawdbot/clawdbot.json and restart the Gateway.

3. Then start the browser profile

clawdbot browser --browser-profile clawd start

Why the Port Conflict Doesn't Matter Right Now

The EADDRINUSE on port 18792 is the Chrome extension relay — you only need that if you want to control your existing Chrome tabs. For the isolated clawd managed browser, port 18791 (control server) + CDP port 18800 are what matter.

Quick Check

After Gateway restart, verify:

clawdbot browser --browser-profile clawd status
#

Should show running: true when working.

wheat stratus
left micaBOT
# wheat stratus

Not a firewall issue — I can see exactly what's happening 🦐

The problem is you're running clawdbot browser serve manually in one terminal, then running the start command from another. When that terminal closes (or you run the start command elsewhere), the control server isn't reachable.

The Fix

You don't need to run clawdbot browser serve manually for local mode.

  1. Stop any running clawdbot browser serve (Ctrl+C in that terminal)

  2. Make sure your ~/.clawdbot/clawdbot.json has the browser config:

{
  "browser": {
    "enabled": true,
    "controlUrl": "http://127.0.0.1:18791"
#
  }
}
  1. Restart the Gateway so it picks up the config:
clawdbot gateway restart
  1. Then start the browser:
clawdbot browser --browser-profile clawd start

The Gateway will automatically start the browser control server on port 18791 when needed.

#

Bonus: Fix the NVM Warning

Your gateway status also shows:

Service config issue: Gateway service uses Node from a version manager; it can break after upgrades.

Run this to fix it:

clawdbot doctor --repair

This migrates to system Node for the service (more stable).

wheat stratus
#

Still the same.

╭─aymene@aymene-nas ~
╰─➤  clawdbot browser --browser-profile clawd start

🦞 Clawdbot 2026.1.24-3 (885167d) — I can grep it, git blame it, and gently roast it—pick your coping mechanism.

Error: Can't reach the clawd browser control server at http://127.0.0.1:18791/start?profile=clawd (timed out after 15000ms). Start (or restart) the Clawdbot gateway (Clawdbot.app menubar, or `clawdbot gateway`) and try again.
╭─aymene@aymene-nas ~
╰─➤  curl -I "http://127.0.0.1:18791/start?profile=clawd"                                                                                                                     1 ↵
HTTP/1.1 404 Not Found
X-Powered-By: Express
Content-Security-Policy: default-src 'none'
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
Content-Length: 145
Date: Mon, 26 Jan 2026 10:43:10 GMT
Connection: keep-alive
Keep-Alive: timeout=5

╭─aymene@aymene-nas ~
╰─➤
left micaBOT
#

If curl works (shows a response), then the server IS reachable and it's a Gateway/browser tool issue. Paste what curl returns.

#

Waiting for your curl result! If it returns something like {"version":"..."}, then the server is reachable and we need to look at how the Gateway is trying to connect to it. If it times out or connection refused, then something else is wrong.

wheat stratus
#

╭─aymene@wheat stratus-nas ~
╰─➤ curl http://127.0.0.1:18791/ 130 ↵
{"enabled":true,"controlUrl":"http://127.0.0.1:18791","profile":"chrome","running":false,"cdpReady":false,"cdpHttp":true,"pid":null,"cdpPort":18792,"cdpUrl":"http://127.0.0.1:18792","chosenBrowser":null,"detectedBrowser":"chromium","detectedExecutablePath":"/usr/bin/chromium-browser","detectError":null,"userDataDir":null,"color":"#00AA00","headless":true,"noSandbox":false,"executablePath":null,"attachOnly":false}%

left micaBOT
# wheat stratus ╭─aymene<@799985366546645012>-nas ~ ╰─➤ curl http://127.0.0.1:18791/ ...

The server is running and reachable! The response shows it's live on port 18791.

Looking at the response, I notice:

  • profile: "chrome" (not "clawd")
  • running: false

This means clawdbot browser serve started the chrome extension-relay profile, not the clawd managed browser profile.

Fix

  1. Kill the current server (Ctrl+C in that terminal or pkill -f "clawdbot browser serve")

  2. Make sure your ~/.clawdbot/clawdbot.json has the browser config:

{
  "browser": {
#
    "enabled": true,
    "controlUrl": "http://127.0.0.1:18791",
    "defaultProfile": "clawd"
  }
}
  1. Restart the Gateway:
clawdbot gateway restart
  1. Now start the clawd browser:
clawdbot browser --browser-profile clawd start
#

The Gateway will now:

  1. Start the browser control server automatically
  2. Configure it for the clawd profile
  3. Launch Chromium with the isolated profile

You shouldn't need to run clawdbot browser serve manually — the Gateway handles that when configured correctly.

wheat stratus
#
╭─aymene@aymene-nas ~
╰─➤  pkill -f "clawdbot browser serve"
╭─aymene@aymene-nas ~
╰─➤  vim .clawdbot/clawdbot.json                                                                                                                                              1 ↵
╭─aymene@aymene-nas ~
╰─➤  clawdbot gateway restart


🦞 Clawdbot 2026.1.24-3 (885167d) — Gateway online—please keep hands, feet, and appendages inside the shell at all times.

Restarted systemd service: clawdbot-gateway.service
╭─aymene@aymene-nas ~
╰─➤  clawdbot browser --browser-profile clawd start


🦞 Clawdbot 2026.1.24-3 (885167d) — I'm like tmux: confusing at first, then suddenly you can't live without me.

Error: Can't reach the clawd browser control server at http://127.0.0.1:18791/start?profile=clawd (timed out after 15000ms). Start (or restart) the Clawdbot gateway (Clawdbot.app menubar, or `clawdbot gateway`) and try again.
╭─aymene@aymene-nas ~
╰─➤  cat .clawdbot/clawdbot.json | grep -A 4 "browser"                                                                                                                        1 ↵
  "browser": {
    "enabled": true,
    "controlUrl": "http://127.0.0.1:18791",
    "headless": true,
    "defaultProfile": "clawd",
╭─aymene@aymene-nas ~
╰─➤
left micaBOT
#

Paste the outputs of these 3 commands — the logs will tell us why the Gateway isn't spawning the browser control server.

wheat stratus
#
╭─aymene@aymene-nas ~
╰─➤  curl http://127.0.0.1:18791/

{"enabled":true,"controlUrl":"http://127.0.0.1:18791","profile":"clawd","running":false,"cdpReady":false,"cdpHttp":false,"pid":null,"cdpPort":18800,"cdpUrl":"http://127.0.0.1:18800","chosenBrowser":null,"detectedBrowser":"chromium","detectedExecutablePath":"/usr/bin/chromium-browser","detectError":null,"userDataDir":null,"color":"#FF4500","headless":true,"noSandbox":false,"executablePath":null,"attachOnly":false}%
╭─aymene@aymene-nas ~
╰─➤  clawdbot gateway status


🦞 Clawdbot 2026.1.24-3 (885167d) — If it works, it's automation; if it breaks, it's a "learning opportunity."

│
◇
Service: systemd (enabled)
File logs: /tmp/clawdbot/clawdbot-2026-01-26.log
Command: /home/aymene/.nvm/versions/node/v22.19.0/bin/node /home/aymene/.nvm/versions/node/v22.19.0/lib/node_modules/clawdbot/dist/entry.js gateway --port 18789
Service file: ~/.config/systemd/user/clawdbot-gateway.service
Service env: CLAWDBOT_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/aymene/.nvm/versions/node/v22.19.0/bin/node)
Service config issue: System Node 22+ not found; install it before migrating away from version managers.
Recommendation: run "clawdbot doctor" (or "clawdbot doctor --repair").
Config (cli): ~/.clawdbot/clawdbot.json
Config (service): ~/.clawdbot/clawdbot.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 126722, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run clawdbot status
Troubleshooting: https://docs.clawd.bot/troubleshooting
left micaBOT
# wheat stratus ``` ╭─aymene@aymene-nas ~ ╰─➤ curl http://127.0.0.1:18791/ {"enabled":true,"co...

Good progress! The server is now running with profile: "clawd"

But notice:

  • running: false
  • chosenBrowser: null
  • userDataDir: null

The server is up, but the browser isn't being launched. The Gateway is trying to call /start?profile=clawd and timing out.

Get the logs:

clawdbot logs --follow

(Leave it running, then in another terminal run clawdbot browser --browser-profile clawd start and paste what appears in the logs)

wheat stratus
#

10:54:11 info {"0":"","_meta":{"runtime":"node","runtimeVersion":"22.19.0","hostname":"unknown","name":"clawdbot","date":"2026-01-26T10:54:11.442Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/aymene/.nvm/versions/node/v22.19.0/lib/node_modules/clawdbot/dist/logging/console.js:181:32","fileName":"console.js","fileNameWithLine":"console.js:181","fileColumn":"32","fileLine":"181","filePath":".nvm/versions/node/v22.19.0/lib/node_modules/clawdbot/dist/logging/console.js","filePathWithLine":".nvm/versions/node/v22.19.0/lib/node_modules/clawdbot/dist/logging/console.js:181","method":"console.log"}},"time":"2026-01-26T10:54:11.442Z"}
10:54:11 info Listening: 127.0.0.1:18789
10:54:11 info Troubles: run clawdbot status
10:54:11 info Troubleshooting: https://docs.clawd.bot/troubleshooting
10:55:33 error Error: Can't reach the clawd browser control server at http://127.0.0.1:18791/start?profile=clawd (timed out after 15000ms). Start (or restart) the Clawdbot gateway (Clawdbot.app menubar, or clawdbot gateway) and try again.

left micaBOT
wheat stratus
left micaBOT
#

The issue is likely:

  1. Missing display (headless mode needs --headless flag properly passed)
  2. Missing Chrome dependencies
  3. Permission issue with the user data directory
wheat stratus
#

╭─aymene@wheat stratus-nas ~
╰─➤ /usr/bin/chromium-browser --version

Chromium 144.0.7559.96 snap
╭─aymene@wheat stratus-nas ~
╰─➤ echo $DISPLAY

╭─aymene@wheat stratus-nas ~
╰─➤

left micaBOT
#
{
  "browser": {
    "enabled": true,
    "controlUrl": "http://127.0.0.1:18791",
    "defaultProfile": "clawd",
    "headless": true,
    "noSandbox": true,
    "profiles": {
      "clawd": {
        "cdpPort": 18800,
        "color": "#FF4500",
        "headless": true,
        "noSandbox": true
      }
    }
#
  }
}
  1. Restart Gateway:
clawdbot gateway restart
  1. Try again:
clawdbot browser --browser-profile clawd start

Snap packages can be tricky with headless mode. If it still fails, the logs will tell us why.

wheat stratus
#
{"0":"\u001b[38;5;167mError: Can't reach the clawd browser control server at http://127.0.0.1:18791/start?profile=clawd (timed out after 15000ms). Start (or restart) the Clawdbot gateway (Clawdbot.app menubar, or `clawdbot gateway`) and try again.\u001b[39m","_meta":{"runtime":"node","runtimeVersion":"22.19.0","hostname":"unknown","name":"clawdbot","date":"2026-01-26T10:55:33.258Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///home/aymene/.nvm/versions/node/v22.19.0/lib/node_modules/clawdbot/dist/logging/console.js:187:32","fileName":"console.js","fileNameWithLine":"console.js:187","fileColumn":"32","fileLine":"187","filePath":".nvm/versions/node/v22.19.0/lib/node_modules/clawdbot/dist/logging/console.js","filePathWithLine":".nvm/versions/node/v22.19.0/lib/node_modules/clawdbot/dist/logging/console.js:187","method":"console.error"}},"time":"2026-01-26T10:55:33.260Z"}
╭─aymene@aymene-nas ~
╰─➤  clawdbot gateway restart

Invalid config at /home/aymene/.clawdbot/clawdbot.json:\n- browser.profiles.clawd: Unrecognized keys: "headless", "noSandbox"

🦞 Clawdbot 2026.1.24-3 (885167d) — If it's repetitive, I'll automate it; if it's hard, I'll bring jokes and a rollback plan.

So I removed them

╭─aymene@aymene-nas ~
╰─➤  cat .clawdbot/clawdbot.json | grep -A 12 "browser"
  "browser": {
    "enabled": true,
    "controlUrl": "http://127.0.0.1:18791",
    "defaultProfile": "clawd",
    "headless": true,
    "noSandbox": true,
    "profiles": {
      "clawd": {
        "cdpPort": 18800,
        "color": "#FF4500",
      }
    }
  },

and it still fails

left micaBOT
# wheat stratus ``` {"0":"\u001b[38;5;167mError: Can't reach the clawd browser control server at...

The config keys headless/noSandbox at the profile level aren't valid. The main-level config is correct.

The real problem: Chrome fails to start on port 18800 — we need to see WHY.

Let's manually test if Chromium can start in headless mode on that port:

/usr/bin/chromium-browser \
  --headless \
  --no-sandbox \
  --disable-dev-shm-usage \
  --remote-debugging-port=18800 \
  --user-data-dir=/tmp/clawd-test-profile \
  --disable-gpu \
  "about:blank" &
#

Then check:

curl http://127.0.0.1:18800/json/version

If this fails, we'll see the real error. Snap Chromium often needs these extra flags for headless server mode.

Also check file logs for more detail:

tail -200 /tmp/clawdbot/clawdbot-2026-01-26.log | grep -i "chrome\|chromium\|18800\|clawd" | tail -30
wheat stratus
left micaBOT
# wheat stratus

Chromium WORKS! The errors are just warnings (AppArmor/dbus for snap), but Chrome is listening on port 18800 ✅

The browser can start — the control server just isn't passing the right flags.

Kill the test browser first:

pkill -f "chromium.*18800"

Now test the control server directly:

curl -X POST "http://127.0.0.1:18791/start?profile=clawd"

If it still fails, let's check what's in the Gateway file logs for more detail:

#
tail -50 /tmp/clawdbot/clawdbot-2026-01-26.log

The control server should have spawned Chrome with --headless --no-sandbox but might be missing some flags. The logs will show the exact command it's trying to run.

wheat stratus
#
{"0":"\u001b[38;5;167mError: Can't reach the clawd browser control server at http://127.0.0.1:18791/start?profile=clawd (timed out after 15000ms). Start (or restart) the Clawdbot gateway (Clawdbot.app menubar, or `clawdbot gateway`) and try again.\u001b[39m","_meta":{"runtime":"node","runtimeVersion":"22.19.0","hostname":"unknown","name":"clawdbot","date":"2026-01-26T11:02:00.759Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///home/aymene/.nvm/versions/node/v22.19.0/lib/node_modules/clawdbot/dist/logging/console.js:187:32","fileName":"console.js","fileNameWithLine":"console.js:187","fileColumn":"32","fileLine":"187","filePath":".nvm/versions/node/v22.19.0/lib/node_modules/clawdbot/dist/logging/console.js","filePathWithLine":".nvm/versions/node/v22.19.0/lib/node_modules/clawdbot/dist/logging/console.js:187","method":"console.error"}},"time":"2026-01-26T11:02:00.760Z"}
left micaBOT
# wheat stratus ``` {"0":"\u001b[38;5;167mError: Can't reach the clawd browser control server at...

Let me get more detail from the file logs, not console logs:

tail -100 /tmp/clawdbot/clawdbot-2026-01-26.log | grep -i "browser\|18791\|18800\|clawd" | tail -30

Also check the control server status:

curl http://127.0.0.1:18791/

And let's see what happens when we directly call start with verbose output:

curl -v -X POST "http://127.0.0.1:18791/start?profile=clawd"

The file logs should have the actual spawn command and any error from the control server. If nothing helpful, check the very end of the file logs:

#
tail -10 /tmp/clawdbot/clawdbot-2026-01-26.log
wheat stratus
#
╭─aymene@aymene-nas ~
╰─➤  curl -v -X POST "http://127.0.0.1:18791/start?profile=clawd"

*   Trying 127.0.0.1:18791...
* Connected to 127.0.0.1 (127.0.0.1) port 18791
> POST /start?profile=clawd HTTP/1.1
> Host: 127.0.0.1:18791
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< X-Powered-By: Express
< Content-Type: application/json; charset=utf-8
< Content-Length: 82
< ETag: W/"52-WKE4MxwtH8ZLteJB2+GwpDMK9ik"
< Date: Mon, 26 Jan 2026 11:14:40 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
<
* Connection #0 to host 127.0.0.1 left intact
{"error":"Error: Failed to start Chrome CDP on port 18800 for profile \"clawd\"."}%
```I have no screen, is it why it's not working ? Should we try to put a dummy screen or whatever ?
left micaBOT
# wheat stratus ``` ╭─aymene@aymene-nas ~ ╰─➤ curl -v -X POST "http://127.0.0.1:18791/start?pro...

No, headless mode should work without a display — we proved that earlier when manual Chrome startup worked!

The problem is the control server isn't passing the right flags to Chrome. Let's see what command it's actually running:

tail -200 /tmp/clawdbot/clawdbot-2026-01-26.log | grep -A 5 -B 5 "spawn\|exec\|chromium\|18800" | tail -40

Quick workaround: Use xvfb (virtual display)

# Install xvfb if not available
sudo apt-get install xvfb

# Kill current control server
pkill -f "clawdbot browser serve"
#

# Start control server with xvfb
xvfb-run -a clawdbot browser serve --bind 127.0.0.1 --port 18791

Then in another terminal:

clawdbot browser --browser-profile clawd start

But first, check the logs to see what command Clawdbot is trying to run — that will tell us if it's missing the --headless flag.

wheat stratus
#
╭─aymene@aymene-nas ~
╰─➤  tail -200 /tmp/clawdbot/clawdbot-2026-01-26.log | grep -A 5 -B 5 "spawn\|exec\|chromium\|18800" | tail -40
╭─aymene@aymene-nas ~
╰─➤  sudo apt-get install xvfb

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
xvfb is already the newest version (2:21.1.12-1ubuntu1.5).
0 upgraded, 0 newly installed, 0 to remove and 45 not upgraded.
╭─aymene@aymene-nas ~
╰─➤  pkill -f "clawdbot browser serve"

╭─aymene@aymene-nas ~
╰─➤  xvfb-run -a clawdbot browser serve --bind 127.0.0.1 --port 18791                                                                                                         1 ↵


🦞 Clawdbot 2026.1.24-3 (885167d) — Works on Android. Crazy concept, we know.

Chrome extension relay init failed for profile "chrome": Error: listen EADDRINUSE: address already in use 127.0.0.1:18792
🦞 Browser control listening on http://127.0.0.1:18791/
Auth: off (loopback only).

Paste on the Gateway (clawdbot.json):
{
  "browser": {
    "enabled": true,
    "controlUrl": "http://127.0.0.1:18791"
  }
}
left micaBOT
wheat stratus
#

It closes right away.

Something is wrong.

╭─aymene@aymene-nas ~
╰─➤  ss -tulpn | grep 18791
tcp   LISTEN 0      511          127.0.0.1:18791      0.0.0.0:*    users:(("clawdbot-gatewa",pid=149814,fd=29))
╭─aymene@aymene-nas ~
╰─➤  ss -tulpn | grep 18792
tcp   LISTEN 0      511          127.0.0.1:18792      0.0.0.0:*    users:(("clawdbot-gatewa",pid=149814,fd=30))
╭─aymene@aymene-nas ~
╰─➤  ss -tulpn | grep 18793
╭─aymene@aymene-nas ~
╰─➤  ss -tulpn | grep 18790                                                                                                                                                   1 ↵
╭─aymene@aymene-nas ~
╰─➤  ss -tulpn | grep 18791                                                                                                                                                   1 ↵
tcp   LISTEN 0      511          127.0.0.1:18791      0.0.0.0:*    users:(("clawdbot-gatewa",pid=149814,fd=29))
╭─aymene@aymene-nas ~
╰─➤

tail -50 /tmp/clawdbot/clawdbot-2026-01-26.log | grep -i "clawd|browser|error"

left micaBOT
wheat stratus
#

So ?

left micaBOT
# wheat stratus So ?

Still waiting for the logs! Please run:

tail -50 /tmp/clawdbot/clawdbot-2026-01-26.log

And paste the output. The logs will show exactly why Chrome fails to start when spawned by the Gateway.

wheat stratus
left micaBOT
# wheat stratus

I can see the issue now. The control server receives the /start request but fails silently — it doesn't log WHY Chrome fails to start.

The problem is likely the snap Chromium package. We proved Chrome works manually with --headless --no-sandbox, but the control server might not be passing the right flags, or snap has restrictions.

Try installing regular Chromium (not snap):

# Remove snap chromium
sudo snap remove chromium

# Install regular chromium
sudo apt-get install chromium-browser

Or use Chrome directly from Google:

#
# Download Chrome
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo apt-get install ./google-chrome-stable_current_amd64.deb

Then update your config to use the new path:

clawdbot config set browser.executablePath "/usr/bin/google-chrome"
# or for chromium-browser:
clawdbot config set browser.executablePath "/usr/bin/chromium-browser"

Restart Gateway:

#
clawdbot gateway restart

Then try:

clawdbot browser --browser-profile clawd start

Snap packages often have AppArmor restrictions that cause issues with headless/server mode. The official Chrome or regular Chromium package should work better.

wheat stratus
#

╭─aymene@wheat stratus-nas ~
╰─➤ sudo apt-get install chromium-browser

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
chromium-browser is already the newest version (2:1snap1-0ubuntu2).
0 upgraded, 0 newly installed, 0 to remove and 45 not upgraded.
╭─aymene@wheat stratus-nas ~
╰─➤ chrom
zsh: command not found: chrom
╭─aymene@wheat stratus-nas ~
╰─➤ chromium-browser 127 ↵

Command '/usr/bin/chromium-browser' requires the chromium snap to be installed.
Please install it with:

snap install chromium

#

Can we increase timeout time ?

left micaBOT
# wheat stratus Can we increase timeout time ?

The timeout is 15 seconds, but the real problem is Chrome fails to start, not that it takes too long. Increasing timeout won't help if Chrome crashes immediately.

But for completeness, try:

clawdbot config set browser.remoteCdpTimeoutMs 60000
clawdbot config set browser.remoteCdpHandshakeTimeoutMs 30000
clawdbot gateway restart

However, we already proved Chrome CAN start manually. The issue is the control server isn't spawning it correctly with snap.

The real fix is to install non-snap Chromium as I suggested. Snap's AppArmor policy prevents the control server from spawning Chrome properly in headless mode.

Want to try removing snap chromium and installing the regular package?

wheat stratus
#

╭─aymene@wheat stratus-nas ~
╰─➤ clawdbot config set browser.remoteCdpTimeoutMs 60000

🦞 Clawdbot 2026.1.24-3 (885167d) — I read logs so you can keep pretending you don't have to.

Updated browser.remoteCdpTimeoutMs. Restart the gateway to apply.
╭─aymene@wheat stratus-nas ~
╰─➤ clawdbot config set browser.remoteCdpHandshakeTimeoutMs 30000

🦞 Clawdbot 2026.1.24-3 (885167d) — Hot reload for config, cold sweat for deploys.

Updated browser.remoteCdpHandshakeTimeoutMs. Restart the gateway to apply.
╭─aymene@wheat stratus-nas ~
╰─➤ clawdbot gateway restart

🦞 Clawdbot 2026.1.24-3 (885167d) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

Restarted systemd service: clawdbot-gateway.service
╭─aymene@wheat stratus-nas ~
╰─➤ clawdbot browser --browser-profile clawd start

🦞 Clawdbot 2026.1.24-3 (885167d) — curl for conversations.

Error: Can't reach the clawd browser control server at http://127.0.0.1:18791/start?profile=clawd (timed out after 15000ms). Start (or restart) the Clawdbot gateway (Clawdbot.app menubar, or clawdbot gateway) and try again.

#

╭─aymene@wheat stratus-nas ~
╰─➤ clawdbot config set browser.remoteCdpTimeoutMs 60000

🦞 Clawdbot 2026.1.24-3 (885167d) — I read logs so you can keep pretending you don't have to.

Updated browser.remoteCdpTimeoutMs. Restart the gateway to apply.
╭─aymene@wheat stratus-nas ~
╰─➤ clawdbot config set browser.remoteCdpHandshakeTimeoutMs 30000

🦞 Clawdbot 2026.1.24-3 (885167d) — Hot reload for config, cold sweat for deploys.

Updated browser.remoteCdpHandshakeTimeoutMs. Restart the gateway to apply.
╭─aymene@wheat stratus-nas ~
╰─➤ clawdbot gateway restart

🦞 Clawdbot 2026.1.24-3 (885167d) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

Restarted systemd service: clawdbot-gateway.service
╭─aymene@wheat stratus-nas ~
╰─➤ clawdbot browser --browser-profile clawd start

🦞 Clawdbot 2026.1.24-3 (885167d) — curl for conversations.

Error: Can't reach the clawd browser control server at http://127.0.0.1:18791/start?profile=clawd (timed out after 15000ms). Start (or restart) the Clawdbot gateway (Clawdbot.app menubar, or clawdbot gateway) and try again.

it stays at 15000

left micaBOT
# wheat stratus ╭─aymene<@799985366546645012>-nas ~ ╰─➤ clawdbot config set browser.remoteCdpTi...

The timeout in the error is still 15s — those config settings don't affect the /start endpoint timeout (that's internal to the control server).

Let's try running the Gateway/browser control through xvfb:

clawdbot gateway stop

# Run gateway with xvfb
xvfb-run -a clawdbot gateway --port 18789

Leave that running, then in another terminal try:

clawdbot browser --browser-profile clawd start
#

If that works, we can configure the systemd service to use xvfb-run permanently.

But honestly, the cleanest fix is removing snap Chromium. It's causing these restrictions:

AppArmor policy prevents this sender from sending this message to this recipient

Want to try that? It's just:

sudo snap remove chromium
sudo apt-get install -y chromium-browser
left micaBOT
# wheat stratus ╭─aymene<@799985366546645012>-nas ~ ╰─➤ clawdbot config set browser.remoteCdpTi...

The 15s timeout is hardcoded in the control server, not configurable. Let's debug the actual spawn command:

# Check what's running on the ports
ss -tulpn | grep -E "1879[0-2]|18800"

# Check Chrome processes
ps aux | grep -i chrom

Then let's see what the control server actually tries to run. Check if there are more detailed logs:

tail -100 /tmp/clawdbot/clawdbot-2026-01-26.log | grep -i "spawn\|exec\|child\|fork"

Also, let's manually test what command the control server SHOULD be running. Try this exact command that Chrome needs for headless snap:

#
# Kill any existing Chrome first
pkill -f "chromium.*18800" || true

# Try running Chrome the way the control server should:
xvfb-run -a /usr/bin/chromium-browser \
  --headless \
  --no-sandbox \
  --disable-dev-shm-usage \
  --remote-debugging-port=18800 \
  --user-data-dir=/tmp/clawd-test \
  "about:blank" &

Then check:

#
curl http://127.0.0.1:18800/json/version

If this works, the issue is the control server isn't wrapping Chrome with xvfb-run when needed.

wheat stratus
#

It worked !!

#

It worked ! let's do a systemd service