在 Android Termux 上使用 OpenClaw Browser Control 时，最容易遇到的一个报错是：

No supported browser found

这篇文章专门解决这个问题，并先回答三个关键问题：

  1. 这篇文章解决什么问题？
    • 解决 Termux 下 OpenClaw 无法识别浏览器、导致 Browser Control 启动失败的问题。
  2. 谁适合阅读？
    • 正在 Android / Termux 环境中部署 OpenClaw，并希望使用浏览器自动化能力的用户。
  3. 读完能获得什么？
    • 一套可复用的诊断顺序、明确的根因判断方法，以及最终可生效的修复配置。

如果你也在 Termux 上跑 OpenClaw，这个坑非常值得提前绕开。

一、问题背景：为什么这个报错容易误导人

No supported browser found 这个报错最容易让人误判成：

  • Chromium 没装好
  • 安装过程损坏
  • 浏览器本体根本不存在

但这次问题真正出在：

  • 浏览器本体是好的
  • 坏的是 OpenClaw 对浏览器路径的识别链路

也就是说，这不是“没装浏览器”的问题，而是“装了，但没被正确发现”的问题。

Termux Browser 故障终端现场

上图对应的是典型故障现场：

  • 已经执行过 pkg install x11-repo && pkg install chromium
  • 但 browser status 里仍然看不到有效的 detectedExecutablePath
  • 最终启动 Browser Control 仍然失败

二、先给结论：真正的根因与修复方案

先说结论，避免你走弯路：

  • 现象：No supported browser found
  • 根因：OpenClaw 自动探测没有命中 Termux 的 Chromium 路径
  • 修复：显式配置 browser.executablePath
  • 兼容参数：同时配上 headless: true 与 noSandbox: true
  • 验收标准：browser status 里的 running / cdpReady / detectedExecutablePath 正常，并且能实际打开页面和截图

也就是说，先修“路径识别”，不要先重装浏览器。

三、排障思路：先切分责任，再决定动哪里

这类问题最容易犯的错，就是一上来就反复重装。

更稳的做法是把问题切成三段验证：

  1. OpenClaw 是否识别到浏览器？
  2. Chromium 可执行文件是否真的存在？
  3. 浏览器本体是否可以独立启动？

这三段验证能帮你快速判断，到底该修安装、修路径，还是修配置。

误判路径与正确路径对比

上图表达的核心就是：

  • 错误路径：看到报错 → 反复安装
  • 正确路径：先判断“是浏览器坏了，还是识别链路坏了”

四、实现步骤：按这 3 段顺序排查

Step 0：先确认前置安装没漏

在 Termux 下安装 Chromium 前，先启用 x11-repo：

1
2
pkg install x11-repo
pkg install chromium

为什么这一步重要？

因为如果连安装来源都不对，后面的排障从第一步就会偏掉。这个属于“前置条件错误”，不是 Browser Control 本身的问题。

Step 1：先看 OpenClaw 的识别状态

1
browser status

重点看这些字段：

  • running
  • detectedExecutablePath
  • chosenBrowser
  • detectedBrowser

如果你看到：

  • detectedExecutablePath: null

那就说明问题大概率在识别链路，不是浏览器本体。

Step 2：验证 Chromium 是否真的存在

1
2
which chromium-browser
ls -l /data/data/com.termux/files/usr/bin/chromium-browser

如果这两条能返回路径，说明：

  • 浏览器已经安装
  • Termux 侧可执行文件存在

也就是说，“没装浏览器”这个方向基本就可以排除。

Step 3：验证浏览器本体能否独立启动

1
chromium-browser --headless --disable-gpu --remote-debugging-port=18801 about:blank

出现类似输出：

1
DevTools listening on ws://127.0.0.1:18801/devtools/browser/...

就说明两件事：

  1. Chromium 本体能启动
  2. DevTools/CDP 通道可用

备注：这条命令会占用前台，看到 DevTools listening 后可 Ctrl+C 退出。

五、为什么真正有效的是“显式配置路径”

当前根因不是浏览器坏了，而是 OpenClaw 自动探测没有命中 Termux 的路径。

Termux 的 Chromium 路径不是很多桌面 Linux 环境里的常见路径，因此自动探测有可能失败。

这就是为什么“重新安装浏览器”没有解决问题——因为问题不在浏览器本体，而在发现机制。

六、最终修复方案

把下面配置加入 ~/.openclaw/openclaw.json：

1
2
3
4
5
6
7
{
  "browser": {
    "executablePath": "/data/data/com.termux/files/usr/bin/chromium-browser",
    "headless": true,
    "noSandbox": true
  }
}

然后重启 gateway：

1
openclaw gateway restart

这三个字段分别解决什么？

  • executablePath
    • 直接告诉 OpenClaw：浏览器就在这里，别再猜。
  • headless: true
    • 让自动化运行更稳定，减少图形环境依赖。
  • noSandbox: true
    • 适配 Android / Termux 环境下的沙箱限制。

换句话说，这不是“随便补三个参数”，而是分别解决：

  • 路径识别
  • 自动化稳定性
  • 运行环境兼容性

七、运行效果：不要凭感觉，要看验收信号

修好之后，不要只看“这次好像能用了”，而要看一组明确验收信号。

修复后终端验证信号

最小验收标准：

  1. browser status 显示：
    • running: true
    • cdpReady: true
    • detectedBrowser: custom
    • detectedExecutablePath 指向 Termux Chromium
  2. 能正常打开页面
  3. 能正常截图
  4. 能关闭标签并退出

只有这些都通过，才算真的修好了。

八、常见问题与坑

1）为什么明明装了 Chromium 还是报没找到？

因为“装好了”和“被上层正确识别”是两回事。

这次问题的关键教训就是：

  • 安装链路成功 ≠ 探测链路成功

2）为什么不建议先重装浏览器？

因为这会把问题从“判断根因”变成“重复做无效操作”。

正确顺序应该是：

  • 先确认文件是否存在
  • 再确认本体能否独立启动
  • 最后才决定是否要修安装

3）生产/长期使用需要注意什么？

如果你后续：

  • 升级 Chromium
  • 更换设备
  • 迁移 Termux 环境

优先复检这几项：

  • browser.executablePath
  • headless
  • noSandbox
  • browser status 的 cdpReady

这些比“再重装一遍”更能快速定位问题。

九、一屏排障清单（可直接照着走）

1
2
3
4
5
6
7
pkg install x11-repo
pkg install chromium
browser status
which chromium-browser
ls -l /data/data/com.termux/files/usr/bin/chromium-browser
chromium-browser --headless --disable-gpu --remote-debugging-port=18801 about:blank
openclaw gateway restart

配套检查点：

  • detectedExecutablePath 是否为空
  • DevTools listening 是否出现
  • running / cdpReady 是否为 true

十、总结

这篇文章的核心结论只有一句：

Termux 下报 No supported browser found，优先修“路径识别”，不要先重装浏览器。

你真正需要记住的是三个关键词：

  • 先切分责任
  • 再判断根因
  • 最后做显式配置

如果后续你还准备在 Termux 上跑更多 Browser / CDP 自动化能力，这个诊断思路可以直接复用，不只是 OpenClaw。