1. OpenClaw 2026.7.2 在 WSL2 下到底卡在哪
OpenClaw 2026.7.2 是一个跑在本地、能读写文件并执行工具调用的开源个人助理框架，它自带 gateway 网关进程和 SQLite 状态存储，适合愿意自己掌控数据、又想让 Codex 这类编码助手接入统一模型通道的人。如果你在 Windows 上直接跑，onboard 向导会明确提示「Windows detected - OpenClaw runs great on WSL2」，因为 gateway 的进程模型、SQLite 的 STRICT 表迁移、以及文件锁行为在原生 Windows 下容易出岔子。我实测下来，最省心的路径就是 WSL2 + Ubuntu，把 gateway 和 SQLite 都放在 Linux 文件系统里，再通过 TaoToken 统一 Key 接入模型通道。
很多人第一次跑node scripts/run-node.mjs "gateway"会直接撞上这段报错：
[gateway] loading configuration… [gateway] resolving authentication… Gateway start blocked: existing config is missing gateway.mode. Treat this as suspicious or clobbered config. Re-run `openclaw onboard --mode local` or `openclaw setup`, set gateway.mode=local manually, or pass --allow-unconfigured. [ELIFECYCLE] Command failed with exit code 78.exit code 78 是配置校验失败，不是崩溃。根因是 settings.json 里缺少gateway.mode字段，而 2026.7.2 把 gateway 模式从「隐式默认」改成了「必须显式声明」。同时 onboard 阶段还会做一次 SQLite 状态迁移，把旧的 audit event ledger 迁到 versioned message lifecycle schema，并把共享状态表切成 SQLite STRICT typing（我这边看到迁移了 71 张表）。如果这一步在 WSL2 的挂载盘（比如/mnt/c/...）上执行，SQLite 的 WAL 锁经常失败，迁移记录会写不完整，下一次启动就报 config clobbered。
所以这篇的路线是：WSL2 里建工作区 → 写一份带 gateway 和 SQLite 的 settings.json 骨架 → 用 TaoToken 的 Key 填模型通道 → 跑 gateway 验证 → 排掉几个高频错。全程命令可直接复制。
2. TaoToken 前置：一把 Key 打通 Codex 与 gateway
OpenClaw 的模型调用走的是 OpenAI 兼容协议，Codex 也是。与其给每个工具单独配一套凭证，不如用 TaoToken 做统一入口：一个 API Key，一个 base URL，gateway 和 Codex 共用。这样 settings.json 里只需要维护一处apiKey和baseUrl，换模型时改model字段就行。
你需要先拿到 Key。打开控制台创建：
https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite创建完在 API Keys 页面复制，形如sk-...。接入文档在这里，遇到字段对不上时对照查：
https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewriteAPI 基地址统一用：
https://taotoken.net/api注意这个地址不带任何查询参数，直接填进配置。如果你只是想先确认 Key 能用、模型能回话，不用急着配 OpenClaw，先去模型对话页发一条消息验证：
https://taotoken.net/model-chat?utm_source=taotoken_aicg_blog_end&utm_content=model-chat&utm_campaign=rewrite长期跑编码任务、想让 Codex 和 OpenClaw 共享额度与调用记录的话，Coding Plan 更合适，后面第 6 节会讲怎么把两者指到同一个通道。
注意：Key 只存在 WSL2 的 Linux 文件系统里，别放到
/mnt/c/Users/...下，也别提交进 git。OpenClaw 的工具能读文件，密钥放在 agent 可达目录等于敞开。
3. 可复制配置：WSL2 下的 settings.json 骨架
先确认你在 WSL2 里，而不是 PowerShell：
uname -a # 期望看到 ... microsoft-standard-WSL2 ...然后建工作区和配置目录。OpenClaw 默认读~/.openclaw/，我们把它固定在 Linux 家目录：
mkdir -p ~/.openclaw/workspace mkdir -p ~/.openclaw/state cd ~/.openclaw接下来是核心的settings.json。这份骨架覆盖 gateway 模式、监听地址、SQLite 路径与 STRICT 迁移开关、以及模型通道。把sk-你的Key替换成上一步复制的值：
{ "gateway": { "mode": "local", "host": "127.0.0.1", "port": 8787, "allowUnconfigured": false, "auth": { "provider": "taotoken", "apiKey": "sk-你的Key", "baseUrl": "https://taotoken.net/api" } }, "model": { "provider": "openai-compatible", "name": "gpt-5-codex", "baseUrl": "https://taotoken.net/api", "apiKey": "sk-你的Key", "timeoutMs": 120000 }, "state": { "driver": "sqlite", "path": "/home/你的用户名/.openclaw/state/openclaw.db", "strictTyping": true, "journalMode": "WAL", "busyTimeoutMs": 5000, "migrations": { "autoMigrate": true, "auditLedgerToLifecycle": true, "matrixInboundDedupe": true } }, "session": { "dmScope": "per-channel-peer" }, "tools": { "sandbox": true, "leastPrivilege": true } }几个字段值得单独说。gateway.mode必须是local，这就是 exit code 78 的直接解药；allowUnconfigured设 false 是为了让配置缺失时立刻报错而不是静默降级。state.path用绝对路径，且必须在 Linux 文件系统内，/mnt/c下的 SQLite 会因为 9p 文件系统不支持可靠的锁而随机损坏。journalMode: WAL配合busyTimeoutMs能显著减少 gateway 与迁移进程并发写时的database is locked。strictTyping: true对应 2026.7.2 的 STRICT 表迁移，保持开启才能让迁移记录完整落库。
把用户名替换成实际值，可以用命令自动填：
sed -i "s#/home/你的用户名#/home/$USER#" ~/.openclaw/settings.json确认 JSON 合法，别让一个逗号毁掉整个启动：
python3 -m json.tool ~/.openclaw/settings.json > /dev/null && echo "JSON OK"4. 验证请求：从 gateway 启动到 Codex 连通
配置写完，先跑一次 setup 让 SQLite 完成迁移，再启 gateway。顺序很重要，反了会因为表结构未就绪而报错：
cd ~/openclaw # 你的 OpenClaw 源码目录 node scripts/run-node.mjs "setup"正常会看到迁移日志，类似：
[state-migrations] Auto-migrated legacy state: - Migrated shared state audit event ledger → versioned message lifecycle schema - Migrated shared state tables to SQLite STRICT typing (71) - Recorded Matrix inbound dedupe migration completion然后启动 gateway：
node scripts/run-node.mjs "gateway"期望输出：
[gateway] loading configuration… [gateway] resolving authentication… [gateway] listening on 127.0.0.1:8787 (mode=local)不再出现 exit code 78 就说明gateway.mode生效了。另开一个 WSL2 终端做连通性检查，先探端口：
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8787/healthz # 期望 200再验证模型通道是否真的能回话。用 TaoToken 的兼容端点直接打一次，确认 Key 和 baseUrl 没问题：
curl -s https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer sk-你的Key" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-5-codex", "messages": [{"role": "user", "content": "reply with OK only"}] }' | python3 -c "import sys,json;print(json.load(sys.stdin)['choices'][0]['message']['content'])"返回OK就说明统一通道打通了。最后确认 SQLite 状态库真的建起来了，并且是 STRICT 表：
sqlite3 ~/.openclaw/state/openclaw.db ".tables" sqlite3 ~/.openclaw/state/openclaw.db "PRAGMA journal_mode;" # 期望输出 wal如果.tables里能看到 message lifecycle 相关的表，说明迁移成功。到这一步，gateway 在跑、SQLite 在写、模型通道能回话，Codex 侧只要把 base URL 指到https://taotoken.net/api、Key 填同一个，就能和 OpenClaw 共享通道。
5. 本篇常见错排查
exit code 78 反复出现。九成是gateway.mode没写或写成了别的值。检查：
python3 -c "import json;print(json.load(open('/home/'+'$USER'+'/.openclaw/settings.json'))['gateway']['mode'])"输出必须是local。如果你之前用--allow-unconfigured启动过，配置可能被标记为 clobbered，删掉~/.openclaw/state/下的临时锁文件再跑 setup。
database is locked或迁移卡住。通常是 state.path 落在了/mnt/c。确认路径：
python3 -c "import json;print(json.load(open('/home/'+'$USER'+'/.openclaw/settings.json'))['state']['path'])"只要出现/mnt/就搬回 Linux 家目录。另外确认没有两个 gateway 进程同时跑：
pgrep -af "run-node.mjs"有多个就 kill 掉多余的，SQLite 单写者模型不允许并发写。
模型调用 401 或 404。401 是 Key 错或没带Bearer；404 多半是 baseUrl 多写了/v1。TaoToken 的基地址就是https://taotoken.net/api，路径由客户端补/v1/chat/completions，别自己拼重复。用第 4 节的 curl 单独测一次，能定位是配置问题还是网络问题。
Codex 连不上但 gateway 正常。Codex 读的是它自己的配置，不是 OpenClaw 的 settings.json。把 Codex 的 base URL 和 Key 手动指到同一组值，别指望它自动继承。两边都指向https://taotoken.net/api后，调用记录才会汇总到同一个 Key 下。
onboard 里 AI check failed: Codex completion failed。这是 onboard 阶段探测 Codex 时模型通道还没配好导致的，属于预期现象。先跳过，按本文把 settings.json 写全，再回头跑openclaw onboard补 AI 配置即可。
6. 把 Codex 和 gateway 收敛到一条通道
配置稳定后，建议把 Codex 的长期编码任务和 OpenClaw 的 gateway 都收敛到 TaoToken 的同一个 Key 上。这样调用额度、模型切换、审计记录都在一处，排障时不用在两个后台之间来回跳。Codex 侧改 base URL 和 Key 后，跑一次真实补全确认：
codex --version # 然后在 Codex 里发一条需要读文件的指令，确认能正常返回如果你打算让 OpenClaw 长期挂着跑、Codex 也高频用，Coding Plan 比按量更划算，开通入口：
https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewriteKey 管理和新建入口在控制台，换 Key 时记得同步更新 settings.json 里的两处apiKey（gateway.auth 和 model 各一处），改完重启 gateway 生效：
https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite字段含义对不上时查接入文档，里面有完整的兼容端点说明：
https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite最后提醒一句：OpenClaw 的工具默认能读文件、执行动作，tools.sandbox和leastPrivilege别关。密钥放在 Linux 家目录、别进 git、别放/mnt/c，这三条守住，本地环境基本就稳了。