1. 先说清楚这个工具踩坑的现场oh-my-opencode 启动卡死这事我前前后后折腾了三天。先说结论这工具本身不背全部锅绝大多数卡死都是启动阶段某个环节在静默等待——等网络、等子进程、等锁——而 TUI 界面上只有一个转圈的光标根本不告诉你它卡在哪。这篇文章把我排查和修复的完整过程写下来包括三个实际遇到的问题、对应的修复方法以及一张可以直接照抄的速查表给同样被 opencode 启动卡死折磨的人参考。如果你还不熟悉 oh-my-opencode简单理解就是 opencode 的社区配置全家桶类似 oh-my-zsh 之于 zsh把模型提供商、skills自定义命令/技能脚本、主题、快捷键这些散乱配置整合成一套开箱即用的方案。听起来很美但它的启动链路比裸 opencode 长得多任何一个环节出问题都会表现为“启动即卡死”。适合本文的读者有两类一是已经装了 oh-my-opencode 但启动就卡的人二是想提前避坑、正在评估要不要上这套配置的人。下面所有排查思路裸 opencode 同样适用。1.1 oh-my-opencode 的启动链路到底比裸 opencode 多了什么裸 opencode 的启动流程大致是读配置文件、加载内置 provider、启动 TUI。而 oh-my-opencode 在这条链路里插了好几层按顺序大概是加载自身主配置 - 扫描并注册所有 skills 目录 - 逐个执行 skill 的 hook 脚本有些是安装时执行有些是每次启动都执行- 读取 provider 配置并做一次预检 - 拉取远端模型列表或版本信息如果有配自动更新- 最后才进入 TUI 渲染。问题就出在这里。前几步里有网络请求、有子进程调用、有文件锁操作任何一个没有超时保护在网络抖动或配置写错的情况下就会无限等下去。TUI 看起来像“卡死”实际上进程还活着只是阻塞在某一个系统调用上。理解了这条链路排查思路就清晰了不是去猜哪里卡而是想办法看到它到底停在第几步。1.2 卡死和慢是两回事先复现再动手我遇到的现象很典型终端里敲 opencodelogo 和加载动画正常出现然后光标停在半路键盘输入没反应CPU 占用几乎为 0按一次 CtrlC 还退不出去要按到第二三次。注意 CPU 为 0 这个细节它说明程序不是在疯狂计算而是在等待某个外部资源。如果是“慢”通常是 CPU 或网络占用持续走高等十几秒也能起来如果是“卡死”等多久都没用。动手排查看似从改配置开始其实应该先做一次干净复现。我当时犯的第一个错误就是在自己满是 alias 和自定义环境变量的 shell 里反复试结果误判成 oh-my-opencode 的问题。后来用/bin/sh -c opencode干净环境跑一遍发现照样卡这才确认是工具自身启动链路的问题。另外建议用timeout 15 opencode; echo $?跑一次退出码是 124 就说明确实卡死在 15 秒内没起来这个判断方式比肉眼盯着转圈靠谱得多。2. 定位卡死环节的三个实用手段排查卡死问题最关键的是先看到“它停在哪一步”。我试过几种方法最有效的就三样看日志、看系统调用、做变量隔离。下面按实用程度排序你不需要全用前两招基本能锁定 80% 的问题。2.1 给启动过程加“探针”日志、超时和系统调用opencode 这类 Go 写的 TUI 工具调试日志一般都在~/.local/share/opencode/log/目录下文件名类似server.log或者按日期命名的日志具体路径不同版本略有差异找不到就find ~/.local/share/opencode -name *.log扫一下。我那次打开日志最后一行停在“Loading skill: git-sync”后面什么都没有范围一下子就缩小到 skill 加载环节。日志不够时上 strace 看系统调用这是定位阻塞点的终极大法。先pgrep -f opencode拿到进程 PID然后strace -f -p 12345 -e tracenetwork,read,write -tt -o /tmp/opencode.strace挂上之后等几秒然后 CtrlC 停掉 strace看输出尾部。我当时看到一堆重复的read(6, , 4096)或poll(...)调用后面跟着connect(3, ...)一直没返回——这基本就是等网络没等到。如果输出里有flock一直卡着那就是锁文件问题如果是大量 CPU 运算指令刷屏那才是死循环。macOS 上没有 strace可以用sample 12345 10抓进程快照效果类似。2.2 用二分法隔离变量找出元凶配置日志和 strace 能告诉你“卡在 skill 加载”但 skill 有十几个到底哪个在作祟还要靠变量隔离。方法很简单先把 oh-my-opencode 的 skills 目录整体改名比如mv ~/.config/opencode/skills ~/.config/opencode/skills.bak确认启动正常后再分批把 skill 目录移回来每次移两三个直到复现卡死就能精确定位到问题 skill。同样的思路适用于所有配置opencode.json改名、主题目录改名、provider 配置逐个注释每改一次跑一次timeout 15 opencode观察是否能越过卡死点。这个过程看起来笨但比瞎猜高效得多。我修第二个问题时就是用这个办法把 provider 预检相关配置摘掉后启动就顺畅了问题锁定在 provider 上。2.3 读懂阻塞类型网络等待、死循环还是锁等待区分阻塞类型决定了修复姿势这一步值得单独说说。最简单的方法是看 CPU阻塞等待时 CPU 接近 0死循环时 CPU 直接拉满跑到 100%。如果 CPU 满的优先怀疑 skill 脚本里写了while true之类的死循环如果 CPU 为 0再看 strace 输出判断是connect/read这类网络阻塞还是flock这类文件锁阻塞。网络阻塞最常见原因通常是配置中的某个 URL 不可达而客户端没设超时。文件锁阻塞比较隐蔽多发生在多个 opencode 实例同时启动、或者上次异常退出残留了锁文件导致新实例启动时拿不到锁。最后还有一种容易被忽略的情况子进程阻塞比如 skill 脚本里调用了 git 或其他命令这个命令本身在等待用户输入或网络父进程 TUI 自然就卡住了。我这次遇到的核心问题就属于这一类下面详细说。3. 我的修复过程三个真实问题逐个击破这次卡死不是单一原因而是三个问题叠加修复过程也分了三步。如果你只遇到其中一个按对应的办法处理就能解决如果都遇到建议按我的顺序来。3.1 第一个问题git-sync skill 的启动自检没有超时日志停在 “Loading skill: git-sync”我第一反应就是去看这个 skill 的 hook 脚本长什么样。打开~/.config/opencode/skills/git-sync/hook.sh核心就一行git pull --rebase --quiet看起来人畜无害但它的问题在于这个 hook 被标记成“每次启动时执行”而 git 命令本身没有超时限制。我的网络环境那几天正好不稳定连接到远端仓库后迟迟拿不到数据git 就静默重试等待父进程 opencode 等子进程退出TUI 就永远卡在加载页。修复方式不是删掉这个 skill而是给 git 命令加上超时和低速保护。git 本身提供http.lowSpeedLimit和http.lowSpeedTime两个参数意思是如果传输速度持续低于某个阈值达到指定秒数直接中断。我又在外面套了一层timeout兜底timeout 15 git -c http.lowSpeedLimit1000 -c http.lowSpeedTime10 pull --rebase --quiet \ || echo git sync timeout or failed, skip /tmp/oh-my-opencode-skill.log这样即使网络再差最多等 15 秒就会跳过。改完再启动果然越过了 git-sync 这一步。这里也暴露了一个设计问题社区 skill 默认假设网络状况良好但真实环境千差万别给所有启动时执行的脚本加超时应该成为使用 oh-my-opencode 的基本习惯。3.2 第二个问题provider 预检阻塞 TUI 渲染绕过了 git-sync启动依然卡只是卡的位置变了这次日志停在 “Checking model providers”。opencode 启动时会对你配置的每个 provider 做一次连通性预检拉取模型列表。如果某个 provider 的 baseURL 写错、API key 无效或者服务端返回异常预检就会卡住尤其是某些自定义 provider 配置里没有设置超时客户端会一直等响应。我当时在opencode.json里配了一个自定义 provider但 API key 直接写了一个占位符字符串而不是引用环境变量。服务端每次收到请求都返回 401客户端拿不到模型列表却也不报错退出而是反复重试。修复分两步第一步先把失效的 provider 从配置里摘掉验证启动恢复正常第二步重新正确配置{ provider: { my-custom: { options: { baseURL: https://api.example.com/v1, apiKey: {env:MY_CUSTOM_API_KEY} } } } }关键点就是用{env:变量名}的方式引用环境变量避免把明文 key 写死在配置里——这不只是安全问题也是启动卡死的诱因因为拼错的 key 会导致启动期鉴权失败。改完记得export MY_CUSTOM_API_KEYxxx后再启动。另外如果你的 provider 本来就不可用最好直接在配置里删掉别留在那里让启动流程反复做无效预检。3.3 第三个问题缓存损坏与版本错配叠加两个核心问题解决后启动基本通畅但还偶发卡死而且没有任何日志报错。这次我用了更细的排查方式用 strace 在卡死瞬间抓系统调用发现卡在一个文件读取上读的是缓存目录里的模型列表 JSON。打开一看文件内容被截断了一半不是合法 JSON加载逻辑读到一半就挂起。原因是我之前多次在启动过程中强杀进程缓存写入没完成留下畸形文件。清理方式是删掉整个缓存目录让它重建rm -rf ~/.cache/opencode顺便说一句缓存目录的位置因系统而异。Linux 下通常在~/.cache/opencodemacOS 下在~/Library/Caches/opencodeWindows 在%LOCALAPPDATA%\opencode\Cache拿不准就全局搜一下opencode目录。清完缓存之后我还顺手查了版本兼容问题。oh-my-opencode 对 opencode 核心版本有明确要求我当时用的 opencode 版本太旧解析不了新版 skills 配置里的某些字段虽然不至于直接卡死但会让部分插件加载异常。解决办法是统一版本要么升级 opencode 到 oh-my-opencode 要求的版本区间要么锁定 oh-my-opencode 到当前核心兼容的旧版具体版本号以项目 README 的 compatibility 说明为准不要盲目追新。4. 常见启动卡死问题速查表经过这次折腾我把启动卡死的常见原因整理成了一张表后面再遇到类似问题基本都是对着表直接查省了大量时间。这张表适合贴在笔记里随时翻。症状可能原因排查手段解决办法卡在 logo / 加载动画CPU 为 0启动时执行了网络请求git pull / provider 预检 / 自动更新看~/.local/share/opencode/log/最后一行日志给相关命令加timeout或设置 git 低速超时临时断开网络测试定位卡在 “Loading skills” 字样skill 的 hook 脚本存在死循环或无网络等待逐个禁用 skills 目录二分定位修复脚本逻辑给所有启动 hook 统一加超时卡在 provider 预检阶段API key 无效、baseURL 不可达、健康检查无超时strace 看connect/read阻塞修正或移除失效 providerkey 改用{env:...}引用偶发卡死无稳定日志缓存目录存在畸形文件检查缓存 JSON 文件是否完整rm -rf ~/.cache/opencode后重启重建配置文件改过之后立刻卡死JSON 语法错误 / schema 版本不兼容python -m json.tool opencode.json验语法修正配置或对齐 opencode 与 oh-my-opencode 版本多个终端同时启动卡死锁文件残留或并发冲突看 strace 里是否有flock阻塞清理/tmp/opencode*锁文件避免并发启动表里最后两行是我在社区和其他项目里也见过的共性问题单独提一下很多朋友改完配置立刻闪退或卡死第一反应是翻配置其实先验一遍 JSON 格式最省事。python3 -m json.tool opencode.json一下语法错误立刻现形。至于并发冲突我建议任何情况下都不要同时开多个 opencode 实例TUI 工具对这种情况普遍没有做很好的处理。5. 预防性建议与我的使用习惯修完问题之后我建立了一套自己的使用习惯这里直接分享出来都是最朴素的工程经验。第一别追新版本。opencode 和 oh-my-opencode 都在快速迭代期每周都有新版本很正常。我的原则是当前组合用得好就不动确实需要新功能再升级升级前先看 release notes 和兼容性说明升完先跑timeout 15 opencode做冒烟测试。第二给所有启动期网络操作加超时。如果你像我一样用多个 skill建议统一检查每个 skill 的 hook 脚本凡是在启动阶段执行的外部命令都要有超时保护。不一定是timeout命令很多脚本语言自己也有超时机制关键是“不能无限等待”这个原则要落实。第三定期清理缓存。我现在每个月清一次~/.cache/opencode就当是给工具做卫生。这个目录里存的是模型列表、临时会话数据之类的东西删了会自动重建唯一的代价是第一次启动会慢几秒。最后再分享一个我个人的小技巧遇到 TUI 工具卡死先别急着重装先pstree -ap $(pgrep -f opencode)看看进程树如果下面挂着一个 git 或 curl 子进程十有八九是网络等待问题如果进程树干干净净但主进程就是不动再往配置和缓存方向查。这个“先看进程树再看日志最后看系统调用”的排查顺序能帮你少走很多弯路。
oh-my-opencode启动卡死排查：从日志到系统调用的完整指南
1. 先说清楚这个工具踩坑的现场oh-my-opencode 启动卡死这事我前前后后折腾了三天。先说结论这工具本身不背全部锅绝大多数卡死都是启动阶段某个环节在静默等待——等网络、等子进程、等锁——而 TUI 界面上只有一个转圈的光标根本不告诉你它卡在哪。这篇文章把我排查和修复的完整过程写下来包括三个实际遇到的问题、对应的修复方法以及一张可以直接照抄的速查表给同样被 opencode 启动卡死折磨的人参考。如果你还不熟悉 oh-my-opencode简单理解就是 opencode 的社区配置全家桶类似 oh-my-zsh 之于 zsh把模型提供商、skills自定义命令/技能脚本、主题、快捷键这些散乱配置整合成一套开箱即用的方案。听起来很美但它的启动链路比裸 opencode 长得多任何一个环节出问题都会表现为“启动即卡死”。适合本文的读者有两类一是已经装了 oh-my-opencode 但启动就卡的人二是想提前避坑、正在评估要不要上这套配置的人。下面所有排查思路裸 opencode 同样适用。1.1 oh-my-opencode 的启动链路到底比裸 opencode 多了什么裸 opencode 的启动流程大致是读配置文件、加载内置 provider、启动 TUI。而 oh-my-opencode 在这条链路里插了好几层按顺序大概是加载自身主配置 - 扫描并注册所有 skills 目录 - 逐个执行 skill 的 hook 脚本有些是安装时执行有些是每次启动都执行- 读取 provider 配置并做一次预检 - 拉取远端模型列表或版本信息如果有配自动更新- 最后才进入 TUI 渲染。问题就出在这里。前几步里有网络请求、有子进程调用、有文件锁操作任何一个没有超时保护在网络抖动或配置写错的情况下就会无限等下去。TUI 看起来像“卡死”实际上进程还活着只是阻塞在某一个系统调用上。理解了这条链路排查思路就清晰了不是去猜哪里卡而是想办法看到它到底停在第几步。1.2 卡死和慢是两回事先复现再动手我遇到的现象很典型终端里敲 opencodelogo 和加载动画正常出现然后光标停在半路键盘输入没反应CPU 占用几乎为 0按一次 CtrlC 还退不出去要按到第二三次。注意 CPU 为 0 这个细节它说明程序不是在疯狂计算而是在等待某个外部资源。如果是“慢”通常是 CPU 或网络占用持续走高等十几秒也能起来如果是“卡死”等多久都没用。动手排查看似从改配置开始其实应该先做一次干净复现。我当时犯的第一个错误就是在自己满是 alias 和自定义环境变量的 shell 里反复试结果误判成 oh-my-opencode 的问题。后来用/bin/sh -c opencode干净环境跑一遍发现照样卡这才确认是工具自身启动链路的问题。另外建议用timeout 15 opencode; echo $?跑一次退出码是 124 就说明确实卡死在 15 秒内没起来这个判断方式比肉眼盯着转圈靠谱得多。2. 定位卡死环节的三个实用手段排查卡死问题最关键的是先看到“它停在哪一步”。我试过几种方法最有效的就三样看日志、看系统调用、做变量隔离。下面按实用程度排序你不需要全用前两招基本能锁定 80% 的问题。2.1 给启动过程加“探针”日志、超时和系统调用opencode 这类 Go 写的 TUI 工具调试日志一般都在~/.local/share/opencode/log/目录下文件名类似server.log或者按日期命名的日志具体路径不同版本略有差异找不到就find ~/.local/share/opencode -name *.log扫一下。我那次打开日志最后一行停在“Loading skill: git-sync”后面什么都没有范围一下子就缩小到 skill 加载环节。日志不够时上 strace 看系统调用这是定位阻塞点的终极大法。先pgrep -f opencode拿到进程 PID然后strace -f -p 12345 -e tracenetwork,read,write -tt -o /tmp/opencode.strace挂上之后等几秒然后 CtrlC 停掉 strace看输出尾部。我当时看到一堆重复的read(6, , 4096)或poll(...)调用后面跟着connect(3, ...)一直没返回——这基本就是等网络没等到。如果输出里有flock一直卡着那就是锁文件问题如果是大量 CPU 运算指令刷屏那才是死循环。macOS 上没有 strace可以用sample 12345 10抓进程快照效果类似。2.2 用二分法隔离变量找出元凶配置日志和 strace 能告诉你“卡在 skill 加载”但 skill 有十几个到底哪个在作祟还要靠变量隔离。方法很简单先把 oh-my-opencode 的 skills 目录整体改名比如mv ~/.config/opencode/skills ~/.config/opencode/skills.bak确认启动正常后再分批把 skill 目录移回来每次移两三个直到复现卡死就能精确定位到问题 skill。同样的思路适用于所有配置opencode.json改名、主题目录改名、provider 配置逐个注释每改一次跑一次timeout 15 opencode观察是否能越过卡死点。这个过程看起来笨但比瞎猜高效得多。我修第二个问题时就是用这个办法把 provider 预检相关配置摘掉后启动就顺畅了问题锁定在 provider 上。2.3 读懂阻塞类型网络等待、死循环还是锁等待区分阻塞类型决定了修复姿势这一步值得单独说说。最简单的方法是看 CPU阻塞等待时 CPU 接近 0死循环时 CPU 直接拉满跑到 100%。如果 CPU 满的优先怀疑 skill 脚本里写了while true之类的死循环如果 CPU 为 0再看 strace 输出判断是connect/read这类网络阻塞还是flock这类文件锁阻塞。网络阻塞最常见原因通常是配置中的某个 URL 不可达而客户端没设超时。文件锁阻塞比较隐蔽多发生在多个 opencode 实例同时启动、或者上次异常退出残留了锁文件导致新实例启动时拿不到锁。最后还有一种容易被忽略的情况子进程阻塞比如 skill 脚本里调用了 git 或其他命令这个命令本身在等待用户输入或网络父进程 TUI 自然就卡住了。我这次遇到的核心问题就属于这一类下面详细说。3. 我的修复过程三个真实问题逐个击破这次卡死不是单一原因而是三个问题叠加修复过程也分了三步。如果你只遇到其中一个按对应的办法处理就能解决如果都遇到建议按我的顺序来。3.1 第一个问题git-sync skill 的启动自检没有超时日志停在 “Loading skill: git-sync”我第一反应就是去看这个 skill 的 hook 脚本长什么样。打开~/.config/opencode/skills/git-sync/hook.sh核心就一行git pull --rebase --quiet看起来人畜无害但它的问题在于这个 hook 被标记成“每次启动时执行”而 git 命令本身没有超时限制。我的网络环境那几天正好不稳定连接到远端仓库后迟迟拿不到数据git 就静默重试等待父进程 opencode 等子进程退出TUI 就永远卡在加载页。修复方式不是删掉这个 skill而是给 git 命令加上超时和低速保护。git 本身提供http.lowSpeedLimit和http.lowSpeedTime两个参数意思是如果传输速度持续低于某个阈值达到指定秒数直接中断。我又在外面套了一层timeout兜底timeout 15 git -c http.lowSpeedLimit1000 -c http.lowSpeedTime10 pull --rebase --quiet \ || echo git sync timeout or failed, skip /tmp/oh-my-opencode-skill.log这样即使网络再差最多等 15 秒就会跳过。改完再启动果然越过了 git-sync 这一步。这里也暴露了一个设计问题社区 skill 默认假设网络状况良好但真实环境千差万别给所有启动时执行的脚本加超时应该成为使用 oh-my-opencode 的基本习惯。3.2 第二个问题provider 预检阻塞 TUI 渲染绕过了 git-sync启动依然卡只是卡的位置变了这次日志停在 “Checking model providers”。opencode 启动时会对你配置的每个 provider 做一次连通性预检拉取模型列表。如果某个 provider 的 baseURL 写错、API key 无效或者服务端返回异常预检就会卡住尤其是某些自定义 provider 配置里没有设置超时客户端会一直等响应。我当时在opencode.json里配了一个自定义 provider但 API key 直接写了一个占位符字符串而不是引用环境变量。服务端每次收到请求都返回 401客户端拿不到模型列表却也不报错退出而是反复重试。修复分两步第一步先把失效的 provider 从配置里摘掉验证启动恢复正常第二步重新正确配置{ provider: { my-custom: { options: { baseURL: https://api.example.com/v1, apiKey: {env:MY_CUSTOM_API_KEY} } } } }关键点就是用{env:变量名}的方式引用环境变量避免把明文 key 写死在配置里——这不只是安全问题也是启动卡死的诱因因为拼错的 key 会导致启动期鉴权失败。改完记得export MY_CUSTOM_API_KEYxxx后再启动。另外如果你的 provider 本来就不可用最好直接在配置里删掉别留在那里让启动流程反复做无效预检。3.3 第三个问题缓存损坏与版本错配叠加两个核心问题解决后启动基本通畅但还偶发卡死而且没有任何日志报错。这次我用了更细的排查方式用 strace 在卡死瞬间抓系统调用发现卡在一个文件读取上读的是缓存目录里的模型列表 JSON。打开一看文件内容被截断了一半不是合法 JSON加载逻辑读到一半就挂起。原因是我之前多次在启动过程中强杀进程缓存写入没完成留下畸形文件。清理方式是删掉整个缓存目录让它重建rm -rf ~/.cache/opencode顺便说一句缓存目录的位置因系统而异。Linux 下通常在~/.cache/opencodemacOS 下在~/Library/Caches/opencodeWindows 在%LOCALAPPDATA%\opencode\Cache拿不准就全局搜一下opencode目录。清完缓存之后我还顺手查了版本兼容问题。oh-my-opencode 对 opencode 核心版本有明确要求我当时用的 opencode 版本太旧解析不了新版 skills 配置里的某些字段虽然不至于直接卡死但会让部分插件加载异常。解决办法是统一版本要么升级 opencode 到 oh-my-opencode 要求的版本区间要么锁定 oh-my-opencode 到当前核心兼容的旧版具体版本号以项目 README 的 compatibility 说明为准不要盲目追新。4. 常见启动卡死问题速查表经过这次折腾我把启动卡死的常见原因整理成了一张表后面再遇到类似问题基本都是对着表直接查省了大量时间。这张表适合贴在笔记里随时翻。症状可能原因排查手段解决办法卡在 logo / 加载动画CPU 为 0启动时执行了网络请求git pull / provider 预检 / 自动更新看~/.local/share/opencode/log/最后一行日志给相关命令加timeout或设置 git 低速超时临时断开网络测试定位卡在 “Loading skills” 字样skill 的 hook 脚本存在死循环或无网络等待逐个禁用 skills 目录二分定位修复脚本逻辑给所有启动 hook 统一加超时卡在 provider 预检阶段API key 无效、baseURL 不可达、健康检查无超时strace 看connect/read阻塞修正或移除失效 providerkey 改用{env:...}引用偶发卡死无稳定日志缓存目录存在畸形文件检查缓存 JSON 文件是否完整rm -rf ~/.cache/opencode后重启重建配置文件改过之后立刻卡死JSON 语法错误 / schema 版本不兼容python -m json.tool opencode.json验语法修正配置或对齐 opencode 与 oh-my-opencode 版本多个终端同时启动卡死锁文件残留或并发冲突看 strace 里是否有flock阻塞清理/tmp/opencode*锁文件避免并发启动表里最后两行是我在社区和其他项目里也见过的共性问题单独提一下很多朋友改完配置立刻闪退或卡死第一反应是翻配置其实先验一遍 JSON 格式最省事。python3 -m json.tool opencode.json一下语法错误立刻现形。至于并发冲突我建议任何情况下都不要同时开多个 opencode 实例TUI 工具对这种情况普遍没有做很好的处理。5. 预防性建议与我的使用习惯修完问题之后我建立了一套自己的使用习惯这里直接分享出来都是最朴素的工程经验。第一别追新版本。opencode 和 oh-my-opencode 都在快速迭代期每周都有新版本很正常。我的原则是当前组合用得好就不动确实需要新功能再升级升级前先看 release notes 和兼容性说明升完先跑timeout 15 opencode做冒烟测试。第二给所有启动期网络操作加超时。如果你像我一样用多个 skill建议统一检查每个 skill 的 hook 脚本凡是在启动阶段执行的外部命令都要有超时保护。不一定是timeout命令很多脚本语言自己也有超时机制关键是“不能无限等待”这个原则要落实。第三定期清理缓存。我现在每个月清一次~/.cache/opencode就当是给工具做卫生。这个目录里存的是模型列表、临时会话数据之类的东西删了会自动重建唯一的代价是第一次启动会慢几秒。最后再分享一个我个人的小技巧遇到 TUI 工具卡死先别急着重装先pstree -ap $(pgrep -f opencode)看看进程树如果下面挂着一个 git 或 curl 子进程十有八九是网络等待问题如果进程树干干净净但主进程就是不动再往配置和缓存方向查。这个“先看进程树再看日志最后看系统调用”的排查顺序能帮你少走很多弯路。
