CodeWhale 断网后如何恢复用 /queue 查看并重新发送离线队列【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/CodewhaleCodewhale 是一个运行在终端里的开源编码代理。当 TUI 会话断网或进入降级/离线状态时你输入的新提示不会丢失而是被排入离线队列并持续写到磁盘。这篇文章说明如何在断网恢复后用/queue命令查看队列内容、逐条重新发送并确认队列文件被正常清除。适用环境是本地 Codewhale CLI/TUI 会话依据来自项目运维手册 docs/OPERATIONS_RUNBOOK.md 的 “Incident: Network Outage / Offline Behavior” 一节。断网期间会发生什么根据 docs/OPERATIONS_RUNBOOK.md 对离线场景的预期行为描述离线模式激活期间新提示词会被排队queued而不是直接发送失败队列状态会持久化到~/.codewhale/sessions/checkpoints/offline_queue.json队列的每次编辑/queue ...都会持续落盘因此草稿和已排队提示在重启后仍然存在见 docs/ARCHITECTURE.md 的 Crash Recovery Offline Queue 一节。这意味着恢复操作的目标很明确确认队列里到底排了什么然后把它重新发出去最后确认持久化文件随之清空。第一步用 /queue list 查看离线队列在 Codewhale TUI 的输入框中直接输入/queue listTUI 会以Queued messages ({count}):的标题列出已排队的消息如果没有任何条目显示No queued messages。/queue支持的子命令为list、send n、edit n、drop n、clearn是队列条目的编号从 1 开始。在另一个终端中用运维手册 “Quick Triage” 一节给出的方式确认持久化文件确实存在、时间戳在更新ls ~/.codewhale/sessions/checkpoints队列文件存在且随排队/编辑动作刷新说明队列状态没有丢可以进入下一步。第二步恢复连接运维手册给恢复动作定的顺序是先恢复连通性再重发队列见 docs/OPERATIONS_RUNBOOK.md。如果怀疑不是本机网络问题而是端点本身不可达可以参考手册 “Turn Hangs or Stream Stops” 一节中的连通性检查命令以 DeepSeek 端点为例curl -sS https://api.deepseek.com/beta/models -H Authorization: Bearer $DEEPSEEK_API_KEY其中$DEEPSEEK_API_KEY是环境中已配置的 API key 变量名来自文档原文该命令只是验证端点可达不会修改任何本地状态。第三步重新发送队列条目连通性恢复后按队列编号逐条重发。运维手册给出的主路径是输入/queue edit n打开第n条排队消息的编辑然后按 Enter 发送或者通过正常输入流程把这条提示重新发出去。TUI 在队列提示中还会给出这两条命令的用法提示/queue send n立即发送第n条/queue drop n删除第n条。如果整批排队内容都不需要了用/queue clear清空队列。验证恢复完成按运维手册的检查项确认两件事再执行一次/queue list确认队列已空显示No queued messages队列清空后持久化的队列文件应当被清除。再次执行ls ~/.codewhale/sessions/checkpoints确认offline_queue.json已不在。两个条件都满足说明离线队列已完整重发并被正常回收。残留旧队列文件时的清理如果队列已经清空、但 checkpoints 目录里仍留着旧的offline_queue.json例如旧版本遗留可以用 setup 的--clean标志处理见 docs/CONFIGURATION.mdcodewhale setup --clean它会先列出~/.codewhale/sessions/checkpoints/latest.json和offline_queue.json若存在加上--force才会实际删除匹配文件。该操作只针对可再生的检查点文件不会触碰真实会话历史或任务队列。副作用是删除 checkpoints 目录中的检查点文件因此只应在确认队列已重发完毕、且你接受放弃这些检查点后使用。对于旧版~/.deepseek/sessions/checkpoints/下的文件不会自动扫描需要一次性清理时设置CODEWHALE_HOME~/.deepseek再执行。如果重发时连接仍然失败或断网伴随流式输出中断等其他症状回到 docs/OPERATIONS_RUNBOOK.md 中的 “Turn Hangs or Stream Stops” 与 “Crash Recovery Needed” 两节继续排查。【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CodeWhale 断网后如何恢复用 /queue 查看并重新发送离线队列【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/CodewhaleCodewhale 是一个运行在终端里的开源编码代理。当 TUI 会话断网或进入降级/离线状态时你输入的新提示不会丢失而是被排入离线队列并持续写到磁盘。这篇文章说明如何在断网恢复后用/queue命令查看队列内容、逐条重新发送并确认队列文件被正常清除。适用环境是本地 Codewhale CLI/TUI 会话依据来自项目运维手册 docs/OPERATIONS_RUNBOOK.md 的 “Incident: Network Outage / Offline Behavior” 一节。断网期间会发生什么根据 docs/OPERATIONS_RUNBOOK.md 对离线场景的预期行为描述离线模式激活期间新提示词会被排队queued而不是直接发送失败队列状态会持久化到~/.codewhale/sessions/checkpoints/offline_queue.json队列的每次编辑/queue ...都会持续落盘因此草稿和已排队提示在重启后仍然存在见 docs/ARCHITECTURE.md 的 Crash Recovery Offline Queue 一节。这意味着恢复操作的目标很明确确认队列里到底排了什么然后把它重新发出去最后确认持久化文件随之清空。第一步用 /queue list 查看离线队列在 Codewhale TUI 的输入框中直接输入/queue listTUI 会以Queued messages ({count}):的标题列出已排队的消息如果没有任何条目显示No queued messages。/queue支持的子命令为list、send n、edit n、drop n、clearn是队列条目的编号从 1 开始。在另一个终端中用运维手册 “Quick Triage” 一节给出的方式确认持久化文件确实存在、时间戳在更新ls ~/.codewhale/sessions/checkpoints队列文件存在且随排队/编辑动作刷新说明队列状态没有丢可以进入下一步。第二步恢复连接运维手册给恢复动作定的顺序是先恢复连通性再重发队列见 docs/OPERATIONS_RUNBOOK.md。如果怀疑不是本机网络问题而是端点本身不可达可以参考手册 “Turn Hangs or Stream Stops” 一节中的连通性检查命令以 DeepSeek 端点为例curl -sS https://api.deepseek.com/beta/models -H Authorization: Bearer $DEEPSEEK_API_KEY其中$DEEPSEEK_API_KEY是环境中已配置的 API key 变量名来自文档原文该命令只是验证端点可达不会修改任何本地状态。第三步重新发送队列条目连通性恢复后按队列编号逐条重发。运维手册给出的主路径是输入/queue edit n打开第n条排队消息的编辑然后按 Enter 发送或者通过正常输入流程把这条提示重新发出去。TUI 在队列提示中还会给出这两条命令的用法提示/queue send n立即发送第n条/queue drop n删除第n条。如果整批排队内容都不需要了用/queue clear清空队列。验证恢复完成按运维手册的检查项确认两件事再执行一次/queue list确认队列已空显示No queued messages队列清空后持久化的队列文件应当被清除。再次执行ls ~/.codewhale/sessions/checkpoints确认offline_queue.json已不在。两个条件都满足说明离线队列已完整重发并被正常回收。残留旧队列文件时的清理如果队列已经清空、但 checkpoints 目录里仍留着旧的offline_queue.json例如旧版本遗留可以用 setup 的--clean标志处理见 docs/CONFIGURATION.mdcodewhale setup --clean它会先列出~/.codewhale/sessions/checkpoints/latest.json和offline_queue.json若存在加上--force才会实际删除匹配文件。该操作只针对可再生的检查点文件不会触碰真实会话历史或任务队列。副作用是删除 checkpoints 目录中的检查点文件因此只应在确认队列已重发完毕、且你接受放弃这些检查点后使用。对于旧版~/.deepseek/sessions/checkpoints/下的文件不会自动扫描需要一次性清理时设置CODEWHALE_HOME~/.deepseek再执行。如果重发时连接仍然失败或断网伴随流式输出中断等其他症状回到 docs/OPERATIONS_RUNBOOK.md 中的 “Turn Hangs or Stream Stops” 与 “Crash Recovery Needed” 两节继续排查。【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
