排障：main:main 会话出现巨大警告三角，聊天页面不可用（OpenClaw 2026.3.12）

社区有人报告：在 OpenClaw 2026.3.12 中，main:main 会话可能进入“无法继续使用”的状态——聊天区域被一个巨大警告三角替换，无法正常输入/继续对话。

来源

Issue： openclaw/openclaw#45442
会话存储位置与语义： Session Management 文档
CLI 查询会话： openclaw sessions

这不是新闻稿，而是一份可落地的恢复手册：先做什么、如何“最小侵入”把 main 会话救回来、以及怎样避免再次踩坑。

症状与触发条件（来自报告）

触发：使用较小的本地模型（例：qwen3:8b / Ollama），让它读取一个偏大的文本文件（约 12KB+）。
随后只有 main:main 这一个会话坏掉：聊天面板变成警告三角。
其他会话仍可正常使用。
重启 gateway 无效。
手动删部分会话文件无效。

快速恢复路径（从低风险到高侵入）

1）先排除“只是 UI 缓存坏了”

如果你用的是 Web Control UI：

强制刷新（Hard refresh）。
换一个浏览器/无痕窗口测试。
清理该站点的站点数据（cookies/localStorage）后重进。

如果只有同一个会话持续出现警告三角，继续往下。

2）如果还能输入，先尝试在对话内重置会话

只要输入框还能打字，直接发：

/reset
/new

这会强制生成新的 session id，常见情况下可以绕开“被污染的上下文/历史”。

如果 main:main 已完全无法输入，就需要从磁盘层“重置该会话的持久化状态”（下一节）。

动手重置前，先保留 3 类证据

巨大警告三角最容易让人冲动删除 main:main 相关会话工件，但这会让后续复盘变得很难。动手前先保留三类证据：

当前 UI 截图或可见错误文案，确认问题不是普通前端渲染抖动；
对应 session 文件、transcript 或本地状态目录的备份路径；
最近一次导致卡死的模型、消息入口和用户输入，方便判断是小模型输出、session 工件损坏，还是入口层异常。

这一步不要求你先修好问题，但能保证后续重置是可回滚、可交接、可复盘的恢复动作。

从磁盘重置 main:main 的会话工件（尽量可逆、可回滚）

OpenClaw 的会话状态属于 gateway 端。

文档给出的典型路径：

会话索引（按 agent）：~/.openclaw/agents/<agentId>/sessions/sessions.json
会话转录（逐会话 JSONL）：~/.openclaw/agents/<agentId>/sessions/<SessionId>.jsonl

默认 agent 一般是 main，所以常见就是：

~/.openclaw/agents/main/sessions/sessions.json
~/.openclaw/agents/main/sessions/<SessionId>.jsonl

main 的直聊主会话 key 通常是 agent:main:main。

步骤 A — 先确认 main 会话存在

运行：

openclaw sessions --all-agents

找到与 main:main 对应的条目（通常会显示 agent:main:main）。

步骤 B — 备份后“挪走”索引/转录，让系统自动重建

目标：不做不可逆删除，而是把可能导致渲染失败的历史暂时移出，让 OpenClaw 在下一次消息到来时自动重建一个干净会话。

1）先停 gateway（避免你改文件时它正好写入）：

openclaw gateway stop

2）创建救援备份目录：

mkdir -p ~/.openclaw/agents/main/sessions/_rescue

3）备份会话索引：

cp ~/.openclaw/agents/main/sessions/sessions.json \
  ~/.openclaw/agents/main/sessions/_rescue/sessions.json.$(date +%Y%m%d-%H%M%S)

4）优先只处理“坏掉那一个会话”的 JSONL 转录：

如果你能在 sessions.json 里定位到对应的 sessionId，把那个 JSONL 挪走：

mv ~/.openclaw/agents/main/sessions/<SessionId>.jsonl \
  ~/.openclaw/agents/main/sessions/_rescue/

如果你短时间找不到具体 sessionId，可以先把整个 sessions.json 临时挪走（OpenClaw 会按需重建条目）：

mv ~/.openclaw/agents/main/sessions/sessions.json \
  ~/.openclaw/agents/main/sessions/_rescue/sessions.json.moved.$(date +%Y%m%d-%H%M%S)

5）启动 gateway：

openclaw gateway start

6）回到 UI，发一条新消息。

预期结果：main:main 被重建为新的 session id，警告三角消失，聊天恢复可用。

这招为什么有效

文档明确说明：会话索引本质是 sessionKey -> { sessionId, ... } 的映射，删掉条目是安全的，会在需要时自动重建。

如果“某一条异常消息/转录状态”触发 UI 渲染失败，让系统生成新的 session id + 新的转录文件，往往能直接打断坏状态。

如何避免再次踩坑（尤其是小本地模型）

报告里的触发条件，是让小模型直接吞入较多的原始文本。

更稳的做法：

1）分块读取：让 agent 分段读取、每段先摘要。 2）先做“结构化摸底”，再深挖：

先列标题/函数列表/关键 TODO
再让你选要深入的部分 3）本地模型建议设置更保守的限制（上下文窗口、工具读取上限），避免一次误操作把主会话拖死。

谁最适合看这篇恢复手册

这篇手册尤其适合下面三类人：

把小型本地模型当日常主力使用的人，因为一次过大的文件读取就可能污染最重要的主会话。
把关键上下文长期放在 main:main 里的操作者，需要在删除任何东西前先走一条最小破坏路径。
需要支持非技术同事的团队，因为巨大警告三角常常会被误报成“OpenClaw 整体坏了”，而不是单会话故障。

先用 60 秒判断：该刷新页面，还是该救 session

如果你是从搜索结果点进来，最容易卡住的不是命令本身，而是先判断问题层级。建议按这个顺序快速分流：

只有一个浏览器坏、换无痕正常：优先清站点数据，不要动 gateway 文件。
只有 main:main 坏、其他 session 正常：优先按单会话持久化状态损坏处理，先备份再挪走对应 transcript。
所有 session 都坏、gateway 日志也异常：不要只盯 main:main，转成 gateway / 模型服务 / Web UI 整体故障排查。
刚刚让小模型读了大文件：把这次读取动作记进证据包，因为它很可能是污染主会话的触发点。

这个分流能减少误删：只有第二种情况才真正需要进入本文的 session rescue 路径。

常见恢复判断问题

什么时候该停止只做 UI 层尝试，转去处理会话文件

如果强刷、换浏览器 profile，以及 /reset 或 /new 都无法解决，而且只有 main:main 坏掉，那么问题大概率已经落在持久化会话状态，而不是浏览器层。

优先挪走单个 JSONL 转录，还是整个 sessions.json 更稳

如果你能定位到准确的 sessionId，优先只挪走对应 JSONL，会更窄、更安全；如果短时间定位不到，挪走 sessions.json 仍然是可回滚的恢复动作，因为 OpenClaw 会按需自动重建条目。

什么时候该停止把巨大警告三角当成 UI 小故障，改判为持久化会话状态已经被污染

如果强刷、换干净浏览器 profile，以及 /reset 或 /new 都试过了，但依然只有 main:main 持续损坏、其他会话正常，那更安全的判断就是问题已经落到持久化会话工件，而不是 UI 层。继续重复前端尝试通常只会浪费排障时间，这时更值得做的是先备份 session store，再强制 OpenClaw 重建坏掉的 session id。

哪些团队最应该先把 main:main 救援手册写好，再允许本地模型在生产环境里读取大文件

如果团队把运维上下文、进行中的事故信息或共享助手历史都放在 main:main，就应该优先把这条恢复路径文档化。尤其当本地模型可以直接读取原始日志、转录或大配置文件时，一次主会话被污染就可能卡住最核心的工作流。提前准备好一份短小可执行的救援手册，能明显减少误删、恐慌和对非技术同事的支持成本。

准备上交给上游或交接给下一位同事前，最值得先收集哪几类证据

在升级处理之前，最好先整理一份最小证据包，让下一位排障的人能快速区分“只是浏览器层异常”还是“持久化 session 状态已经被污染”：

警告三角出现前最后一次触发问题的 prompt，或那次读取文件的具体动作
openclaw sessions --all-agents 里显示的 session ID，以及它和 agent:main:main 的对应关系
警告三角界面的截图，以及它第一次出现的大致时间戳
问题读取动作发生前后，或 UI 第一次刷新失败前后的 gateway 日志片段

这份交接包能帮助下一位更快判断：下一步该做安全的本地 reset、备份并挪走 transcript，还是直接提交一份可复现的上游 bug 报告。

如果你要给团队补一个“高风险读取前检查”，最值得先写哪三条

建议把下面三条写成固定 preflight：

本次是否真的需要把完整大文件直接喂给小模型，还是可以先让它只列结构、标题和关键段落。
当前操作是不是发生在最重要的 main:main 会话里，如果是，是否应该先切到临时会话再试。
出问题后谁来执行 session rescue，备份目录、会话路径和恢复命令是否已经提前写清楚。

这三条很朴素，但能明显降低“为了省一步操作，结果把主会话一起拖死”的概率。

FAQ：遇到巨大警告三角时，最先该怎么判断

如果只有 `main:main` 坏掉，其他 session 都正常，最该先下什么结论？

最值得先下的结论是：先把它当成单会话持久化状态损坏，而不是整站或整个 OpenClaw 全面不可用。

这个判断很关键，因为它会直接决定你下一步是继续反复刷新 UI，还是转去备份并重建坏掉的 session 工件。只要其他 session 仍能正常工作，优先级就应该落在“保住主会话以外的可用链路”，再对 main:main 做窄范围修复。

如果团队担心误删历史，最低风险的恢复顺序应该是什么？

最低风险顺序通常是：先备份，再挪走单个坏会话，再考虑更大范围的索引重建。

也就是说，不要一上来就删整个 session store。先确认 agent:main:main 对应的 sessionId，优先移动那一个 JSONL transcript；只有在短时间内无法精确定位时，再临时挪走 sessions.json 让系统自动重建。这样最容易回滚，也最适合值班同事接手。

什么情况下，这个问题更应该被当成“生产事故”，而不是单人本地故障？

如果 main:main 承载了值班上下文、共享操作历史，或正在进行中的事故排障记录，就应该把它按生产事故处理。

因为这时损失的不只是一个聊天窗口，而是团队的连续上下文。一旦多人依赖这条主会话协作，恢复目标就不该只是“让页面重新能输入”，而应该包括：先保全证据、先保护其他可用会话、再恢复主通道。

重置 session 前的排查清单

在强制重置 main session 前，先保留足够证据，避免把真正的故障模式一起抹掉：

记录大警告三角是在第一个 assistant token 流出前出现，还是流出后出现。
确认同一账号是否能打开一个新的非 main session，且不会出现同样的大警告 UI。
保存可见错误文案、浏览器 console 错误，以及最近一条 gateway/session 日志时间戳。
最后再尝试软刷新，因为 reset 虽然可能清掉症状，也可能清掉定位异常状态迁移所需的线索。

这样能帮助值班者快速区分纯 UI 回归，和会让聊天不可用的 session-state 故障。

搜索意图补强：用户搜这个问题时，真正想解决的通常是什么

实际搜索里，用户通常不会一开始就搜“main:main 巨大警告三角”这种完整表述，而是带着症状和紧急感进来，比如：

“OpenClaw 读完大文件后主会话坏了”
“main:main 变警告三角不能输入”
“OpenClaw 本地模型读取文件后聊天不可用”
“怎么重置损坏的 OpenClaw 主会话”

所以这篇页面要优先快速回答三类高意图问题：

能不能不删全部历史就恢复？ 大多数情况下可以，先备份，再挪走损坏会话工件即可。
这是整个 OpenClaw 都挂了吗？ 通常不是，如果其他 session 正常、只有 main:main 损坏，更像是单会话持久化状态问题。
操作者下一步最稳的动作是什么？ 不要继续只做 UI 重试，先备份持久化 session 状态，再强制重建干净会话。

把这几个判断提前说清楚，能减少误删、误判和无效重试，也更贴近真实搜索入口的意图。

恢复后先做 4 个确认

如果你已经把 warning triangle 处理掉了，也别马上当成彻底结束。先做这 4 个确认：

原来坏掉的 main:main 真的能继续输入和发送。
其他 session 仍然正常，说明这次处理没有误伤更大范围。
被挪走的会话工件已经保留备份，而不是直接永久删除。
再打开一次同样的主会话路径时，不会立刻回到警告三角。

这一步的目标不是“看起来修好了”，而是确认主会话恢复、旁路没坏、证据也还在。

仍无法恢复怎么办

如果上述步骤依然不行：

抓取 warning triangle 出现前后的 gateway 日志。
把复现步骤、OpenClaw 版本、你的 session 存储结构补充到 issue 中。

上游跟踪： openclaw/openclaw#45442

把警告三角流量导向正确下一步

如果这篇是搜索进来的第一落点，先按症状选下一步，不要一上来就全量重置：

只有一个 session 不可用，其他 session 正常：先保留故障 session 文件夹，开一个干净替代 session，再比较 model/runtime 差异，不要直接删除。
所有 session 都开始出现警告三角：不要当成单个 session 损坏，先查 gateway 健康、provider auth 和最近是否改过模型覆盖。
切到小本地模型后才出现：先缩短上下文，换更强 fallback model 复测，再判断 transcript 工件是否真的坏了。

这样高意图读者会先判断影响范围，再只重置最小必要部分，避免把可恢复现场一次性清掉。

值班落地：把这篇文章变成一张 5 分钟恢复卡

如果团队里不止一个人会碰到这个问题，最值得做的不是把本文收藏起来，而是把它压缩成一张内部恢复卡：

第一行写判断边界：只有 main:main 坏，还是所有 session 都坏。
第二行写最小动作：先备份，再只移动可定位的坏 transcript。
第三行写升级条件：如果新 session 也坏、gateway 日志报错、provider auth 同时异常，就停止单会话修复，转整体链路排障。
第四行写禁止动作：不要在没有备份、没有 sessionId、没有截图和日志时间戳时直接清空 session store。

这段能承接从搜索进来的高意图读者：他们通常不是想读完整事故复盘，而是想在 5 分钟内知道“现在该不该动文件”。

值班指挥交接：三句话说明当前状态

当主会话已经卡住，最容易浪费时间的是每个人都重新问一遍“现在到底坏在哪里”。把交接压缩成三句话：

影响面：只影响 main:main，还是所有 session / Web UI 都受影响。
已保全证据：截图、sessionId、最后一次触发动作、gateway 日志时间点是否已经保存。
下一步动作：继续 UI 侧重试、移动单个 JSONL、还是升级到 gateway / provider / auth 排障。

这三句话能让接手的人立刻判断是不是单会话状态损坏，避免把可逆恢复误做成全局清理，也能把搜索访客从“看到巨大警告三角”推进到可交接的值班流程。

如果恢复后又复发，先看这 5 个回流信号

警告三角清掉后又回来，通常说明你只清掉了症状，还没有找到触发条件。复发时先记录这 5 个信号：

是否仍然只影响 main:main：如果复发范围扩大，立刻从单会话恢复切到 gateway / provider 链路排障。
是否总在读取大文件后复发：把文件大小、模型、上下文窗口和最后一条 tool 输入一起保存。
是否只在某个 runtime 复发：记录 model/provider/runtime 覆盖，避免把模型能力边界误判成 UI 故障。
是否刷新后短暂正常又坏掉：这更像持久化状态重新加载时失败，不要只做浏览器缓存清理。
是否新 session 也开始异常：一旦新 session 复现，就不要继续移动旧 transcript，优先查全局配置和 gateway 日志。

这组信号能把“又坏了”变成可定位的复发模式，也能帮助搜索访客判断该继续本地止血，还是补完整 issue 交给上游。

复盘后，用这 4 个演练避免下次误删主会话

警告三角事故恢复以后，团队最该补的不是更多截图，而是一次低风险演练。把下面 4 个动作跑通，下一次主会话坏掉时就不会靠猜：

定位演练：从 UI 上的 agent/session 名称反查真实 transcript 或 session 工件路径，确认值班者知道该动哪一个文件。
备份演练：把目标工件复制到临时目录，并记录恢复命令，避免“先删再说”。
替代通道演练：新开一个干净 session，确认还能继续给用户或团队输出最小可用答复。
回滚演练：把备份工件放回去并重启相关进程，确认团队知道如何撤销一次错误移动。

这 4 个演练能把本文从应急修复变成团队运行手册，尤其适合把 main:main 当作长期工作台的自托管团队。

如果搜索流量来自模型切换后，先区分 UI 故障和上下文压力

如果巨大警告三角刚好出现在切换模型或 runtime 之后，很容易被误判成 Web UI 自己坏了。对值班流量来说，更快的分法是：到底是 UI 自身失败，还是所选模型先撞到了上下文边界。

移动 session 文件之前，先查这几条分支：

读取大文件后出现警告三角：先记录文件大小、模型、runtime 和最后一次 tool call，再考虑重置。
换更强 fallback model 后同一轮能继续：优先按模型/上下文压力处理，缩小复现范围，不要直接归咎整个 UI。
模型还没开始输出页面就失败：保留浏览器 console 和 gateway 日志，因为问题可能在 session-state 加载，不是生成过程。
新 session 仍然健康：把修复范围锁在损坏的 main session，不要清理无关历史。

这段给搜索访客一个更安全的第一过滤器：先证明 context/model 触发，再动持久化 session 工件。

动 session 存储前，先做一次无破坏 preflight

在移动 transcript、重命名 session 文件夹或清浏览器状态之前，先跑一次短的无破坏检查。目标是证明巨大警告三角到底绑定在一个持久化 session、一个浏览器 profile，还是整个 OpenClaw runtime。

新开一个临时 session 发极短 prompt：如果新 session 正常，故障大概率只落在旧 main:main 状态。
抓 reload 后第一条 gateway 错误，不要只看最后一屏噪声栈；第一条通常更能说明是 session 加载、provider auth，还是响应渲染失败。
写下最后一个高风险动作：大文件读取、模型切换、浏览器刷新、手工改 transcript，还是 gateway restart。
最后再选恢复路径：UI 缓存清理、单 transcript 隔离，或 gateway/provider 全链路排查。

这段 preflight 故意很保守。它能避免 warning triangle 事故里最贵的错误：还没分清是本地、单 session 还是全局问题，就先删掉了唯一有用的证据。

从 warning triangle 流量转成 UI 严重度分流

如果你是因为主会话里出现巨大 warning triangle、聊天区不可用或主 session 被遮挡搜到这里，先把问题按影响面分流，而不是只截图报错。第一层判断是：输入框是否还能发送、历史消息是否还能滚动、刷新后是否复现、同一账号在其他频道是否也被遮挡。

最小证据包建议包含一张全页截图、浏览器宽度、当前 channel、触发前最后一条 agent 输出，以及刷新后的复现结果。只有当 warning triangle 稳定阻塞输入或阅读时，才应升级为主会话 P0/P1 UI bug；如果只是单条消息渲染异常，则先按内容渲染或 markdown fallback 路径排查。

什么时候该升级给上游，而不是继续本地清理

本地止血能恢复工作台，但不能替代上游定位。出现下面任一情况时，应该把问题升级成可复现的 UI / session bug：

新 session 也开始出现巨大警告三角：说明问题已经不再局限于旧 main:main 状态，继续移动旧 transcript 只会浪费现场。
刷新后稳定复现并阻塞输入：这已经是可用性问题，不是普通渲染瑕疵，需要带浏览器宽度、channel、console 和 gateway 首条错误一起提交。
同一 transcript 放回后立刻复发：保留备份文件和复发时间点，让维护者能判断是持久化解析失败、消息内容渲染失败，还是 session index 异常。
更换模型或 provider 不能绕过：如果 fallback model 也无法继续，排查重点应从模型上下文压力转向 UI 状态加载或 gateway 层。

升级时不要只贴“页面有个三角”。最小有效包是：全页截图、OpenClaw 版本、session 名称、最后一次高风险动作、gateway 第一条错误、是否新 session 正常，以及你已经做过哪些无破坏 preflight。这样 issue 才能从“无法复现”变成维护者可直接分层排查的材料。

判断是不是该临时切换到备用入口

如果主会话已经被巨大 warning triangle 挡住，别把所有恢复动作都押在同一个 UI 入口。先判断是否需要临时切到备用入口，保证排障时还有一条可控链路。

建议在三种情况下立即切换：第一，主会话输入框无法发送；第二，刷新后仍无法读取历史消息；第三，当前页面正承载部署、外部消息或付费 API 这类有副作用任务。备用入口可以是新 session、CLI、其他 channel，或只读日志检查路径。

这能覆盖“OpenClaw main session unusable what now”“warning triangle blocks chat input”这类搜索意图，把读者从反复刷新推进到先保控制面、再修主会话。