最近在 Hacker News 上看到一个很有针对性的展示项目Save Claude, codex, Grok and OpenCode sessions to an infinite canvas。一句话概括它把 Claude Code、Codex、Grok、OpenCode 这些终端 AI 编程工具散落在本地的会话记录全部导入到一张可缩放、可搜索、可对比的无限画布里解决“用的时候很爽回头根本找不到上下文”的问题。为什么要关心这个现在 Claude Code、Codex、OpenCode、Grok build 都在密集更新很多人刚装完工具、刚配好模型接口跑完一堆会话之后发现记录全是本地 JSONL 文件。想翻一下昨天解决了什么问题只能 grep想对比两个会话的决策差异只能开两个文件来回切想把手上的上下文整理给团队看更是麻烦。这个项目就是奔着这个痛点去的。项目最值得关注的点很清晰不跑模型、不吃显存普通电脑就能跑支持多个主流 AI 编程工具的会话来源可以批量扫描历史会话以本地 Web 服务方式运行会话数据不经过第三方服务器最终呈现形式是无限画布比纯文本日志直观得多。这篇文章会把完整链路走一遍四类工具的会话文件到底存在哪、本地部署需要什么环境、怎么启动服务、怎么导入历史会话、画布上怎么验证效果、批量任务和 API 怎么接、最后是常见问题和合规边界。如果你也是这几款工具的重度用户建议先收藏再往下看。1. 核心能力速览先把关键信息列出来方便你快速判断这个项目适不适合自己。能力项说明项目定位AI 编程会话可视化与回顾工具会话来源Claude Code、Codex、Grok、OpenCode核心功能将本地 JSONL 会话解析后导入无限画布节点化浏览与搜索运行方式本地 Web 服务浏览器访问硬件门槛极低无需 GPU普通办公电脑即可支持平台Windows / macOS / Linux取决于依赖环境是否支持批量任务支持批量扫描历史会话目录是否支持 API依项目实现而定可尝试按接口服务集成数据隐私会话文件只在本机读取与渲染适合本地使用适合场景会话复盘、上下文整理、多会话对比、技术交接需要说明这里不涉及模型推理所以不会有“4G 显存还是 8G 显存”的讨论。真正的变量在会话文件数量和浏览器渲染性能上。2. 这个项目解决的是什么问题终端 AI 编程工具现在的工作方式基本都是在目录里生成一个长对话式会话。Claude Code 会在本地按项目目录写 JSONLCodex 也会把每次会话记录成结构化日志OpenCode 同样有本地存储。问题是这些文件适合程序读取不适合人类回看。你可以把无限画布理解为把“时间线日志”改造成“空间地图”。每次会话变成一个节点集合消息、命令、代码改动、模型输出都展开在画布上。想回看某个问题是怎么解决的直接找到对应会话沿着节点走一遍想对比两次方案把两个会话拖到同一块视野里并排看。适合这个工具的人主要有几类经常同时开多个 AI 编程任务的重度用户需要把会话整理成文档或交接给同事的开发者想研究 Claude Code、Codex、OpenCode 提示词效果差异的玩家以及单纯受够了命令行日志的“长期主义者”。不适合的场景也有如果团队需要跨公网协作且没有做好脱敏直接把含密钥的会话分享出去是有风险的如果只是想快速复制一段代码用原工具体验反而更快。这个项目更偏“事后的整理与复盘”不是实时交互工具。3. 四类工具的会话文件到底存在哪在部署之前先弄清楚会话数据的来源。下面这些是各工具常见的本地存储位置具体以你本机的实际安装版本为准。3.1 Claude Code 会话位置Claude Code 的会话记录通常存放在用户目录下的.claude/projects里。每个项目对应一个以项目路径编码命名的子目录子目录下有.jsonl文件里面按行记录消息、工具调用、命令执行结果等内容。# Linux / macOS ls ~/.claude/projects/ # Windows dir %USERPROFILE%\.claude\projects如果你不确定自己的会话存在哪可以直接搜索*.jsonl定位到最近修改时间对得上的目录即可。3.2 Codex 会话位置Codex 的会话记录一般也在用户目录下常见的是.codex/sessions。每次会话会生成独立的 JSONL 文件文件名通常包含会话 ID 或时间信息。通过会话导入工具解析这个目录就能把历史记录批量还原成画布节点。ls ~/.codex/sessions/3.3 OpenCode 会话位置OpenCode 的本地数据目录跟平台有关。在 macOS 和 Linux 上常见位置是~/.local/share/opencodeWindows 上则可能是%USERPROFILE%\.local\share\opencode或%APPDATA%\opencode。具体需要打开目录确认里面同样会看到会话记录文件。3.4 Grok 会话位置Grok 是这几个来源里比较特殊的一个。Grok 的会话更多在云端侧管理命令行工具如 Grok build 是否有稳定的本地 JSONL 导出格式不同版本差异较大。如果你的 Grok 会话可以通过官方方式导出或保存到本地再把它放进项目支持的目录结构中如果只有云端会话那可能需要先手动导出或者把关键内容整理成兼容格式再导入。这块是本项目里兼容性最需要现场验证的部分。4. 本地部署环境准备这个项目不依赖 GPU环境准备要简单得多核心是保证语言运行时和会话目录可读。4.1 操作系统建议Windows 10/11、macOS、主流 Linux 发行版都可以。关键是能正常安装 Node.js 或 Python 依赖。如果你已经在用 Claude Code、Codex 或 OpenCode说明基础终端环境是没问题的。4.2 运行时要求具体用 Node.js 还是 Python取决于项目本身的技术栈。这里给一个通用检查清单# 检查 Node.js如果项目基于 Node node -v npm -v # 检查 Python如果项目基于 Python python --version pip --version # 检查 Git git --versionNode.js建议 18 或更高版本。Python建议 3.9 或更高版本。如果两个运行时都装了也不用担心部署时按项目 README 选择对应启动方式即可。4.3 磁盘与端口会话 JSONL 文件单个通常只有几十 KB 到几 MB即使上万条消息也不会太大磁盘占用不用担心。启动前检查一下常用端口是否被占用如果项目默认监听 3000 或 5173而本机已经有其他服务占用了后面启动时会报错需要手动换端口。4.4 前置准备清单# 确认会话目录存在 ls -la ~/.claude/projects 2/dev/null || echo not found ls -la ~/.codex/sessions 2/dev/null || echo not found ls -la ~/.local/share/opencode 2/dev/null || echo not found命令输出后能看到的目录就是后续要导入的数据源。如果一个目录都不存在说明对应工具还没产生过会话先跑一次对话再回来继续。5. 安装部署与启动方式由于输入材料没有给出具体的仓库地址和包名这里我给出一个通用的本地部署流程模板。实际使用时把仓库地址、目录名、端口号替换成项目 README 里的真实值。5.1 克隆代码并安装依赖git clone project-repo-url cd project-directory如果项目是 Node.js 技术栈npm install npm run dev如果项目是 Python 技术栈pip install -r requirements.txt python app.py --host 127.0.0.1 --port 3000需要特别说明这不是真实项目的启动命令只是通用结构。实际命令以项目文档为准重点看两个信息一是依赖安装方式二是启动脚本名。5.2 配置会话目录项目一般会提供一个配置文件或环境变量用来指定各工具的会话目录路径。示例配置如下具体字段名需要按项目实际调整{ sessions: { claude: /Users/yourname/.claude/projects, codex: /Users/yourname/.codex/sessions, opencode: /Users/yourname/.local/share/opencode }, host: 127.0.0.1, port: 3000, batchScan: true }Windows 下路径写成C:/Users/yourname/.claude/projects这种形式通常更稳妥。如果项目支持环境变量方式可以在启动前设置export CLAUDE_SESSIONS_DIR/Users/yourname/.claude/projects export CODEX_SESSIONS_DIR/Users/yourname/.codex/sessions export OPENCODE_SESSIONS_DIR/Users/yourname/.local/share/opencode5.3 启动与访问启动成功后终端会打印本地访问地址。按默认情况浏览器打开http://127.0.0.1:3000如果端口被占用启动日志里会有EADDRINUSE之类的报错这时候换一个端口重新启动。服务只监听本机地址其他人不能通过网络直接访问这对隐私来说是个合理默认值。5.4 验证服务是否跑通启动后打开页面先看两个信号页面是否能正常渲染出“无限画布”底色或空画布界面。终端日志里是否能识别到配置的会话目录。如果页面能打开但没有任何会话不是部署失败了而是还没触发会话导入下一步进入功能测试。6. 功能测试与效果验证部署成功后建议按下面的顺序逐个验证功能先导入少量会话再扩大范围这样遇到问题好定位。6.1 导入 Claude Code 会话测试目的确认 JSONL 会话能被正确解析消息顺序和工具调用能还原到画布上。操作步骤在项目界面或命令中输入 Claude 会话目录路径。触发导入。观察画布是否生成一个或多个会话节点。预期结果导入完成后画布上出现会话节点节点之间按消息顺序连接点击节点能看到消息原文、命令内容和模型输出。判断成功的标准会话数量与.claude/projects下的项目目录数量大致匹配并且消息顺序和原始终端显示一致。常见失败原因如果某个 JSONL 文件格式不兼容项目可能跳过该文件或报解析错误。先检查该文件是否能正常打开再看日志中是否提示行解析失败。6.2 导入 Codex 会话测试目的验证多来源会话目录共存的情况。操作步骤把 Codex 会话目录加入配置或通过界面选择。执行导入。在画布中查看 Codex 会话是否与 Claude Code 会话区分展示。预期结果Codex 会话能独立形成节点组不同来源的会话最好有不同颜色或标签方便区分。判断成功的标准导入后能准确识别会话来源不会把 Claude Code 和 Codex 的消息混在同一个节点里。6.3 导入 OpenCode 会话测试目的验证跨平台目录路径兼容性。Windows 上路径经常带空格或中文用户名需要确认配置解析是否正确。如果项目支持目录选择器直接通过界面选择比手写路径更稳。6.4 处理 Grok 会话测试目的确认云端会话或本地导出会话的导入路径。如果 Grok 没有稳定的本地 JSONL 文件可以考虑把重要会话手动导出为 Markdown 或 JSON 后再按项目支持的格式导入。这一部分需要现场查看项目文档是否提供了兼容模板。6.5 画布操作验证导入会话后重点测试以下操作画布缩放滚轮缩放是否流畅。画布平移拖拽移动是否卡顿。节点点击是否能查看消息详情。搜索过滤按关键词搜索是否能在画布中定位到对应节点。多会话并排是否能把两个会话拖到同一视野内对比。如果会话数量只有几十个这些操作都应该很顺滑如果导入几千条消息后界面明显变卡就要考虑分批导入或依赖项目的懒加载机制。6.6 批量扫描验证测试目的确认能不能一次导入全部历史会话而不是手动逐个添加。操作步骤在配置里开启批量扫描。指向包含多个项目子目录的上级目录。触发扫描。预期结果所有历史会话被自动发现并导入画布上生成多个节点组。判断成功的标准导入成功后画布上节点总数与本地会话文件数量基本对应而且页面没有崩溃。7. 接口 API 与批量任务如果项目提供了 HTTP API 接口那么可以把它接进自己的自动化流程比如定时备份、批量导入、生成会话报告。下面是一个通用 API 调用示例实际接口路径和参数需要以项目文档为准。7.1 触发导入接口假设项目提供了一个类似/api/import的接口可以用 curl 做一次导入测试curl -X POST http://127.0.0.1:3000/api/import \ -H Content-Type: application/json \ -d { source: claude, path: /Users/yourname/.claude/projects }正常响应会返回导入状态、本次导入的会话数量和失败数量。如果接口不存在会返回 404 或路由错误这时候以项目 README 为准。7.2 Python 批量调用示例如果需要批量导入多个来源可以写一个简单的 Python 脚本import requests API_BASE http://127.0.0.1:3000 def import_sessions(source: str, path: str) - None: resp requests.post( f{API_BASE}/api/import, json{source: source, path: path}, timeout300, ) print(source, resp.status_code, resp.json()) import_sessions(claude, /Users/yourname/.claude/projects) import_sessions(codex, /Users/yourname/.codex/sessions) import_sessions(opencode, /Users/yourname/.local/share/opencode)批量导入时的建议第一次先导入单个来源确认解析没问题再扩展。大批量导入前先记录本地会话文件数量方便对比结果。如果导入过程中断要有“跳过已导入文件”的去重机制避免重复解析。接口调用建议超时设置长一点比如 300 秒因为大量 JSONL 解析会比较慢。7.3 批量任务的失败重试批量导入最常见的失败情况是某个会话文件损坏或格式不兼容。工程上建议把失败文件单独记录不要中断整个队列failed [] for session_file in session_files: try: import_one(session_file) except Exception as exc: failed.append((session_file, str(exc))) print(failed:, len(failed)) for f in failed: print(f)这样即使有一两个文件解析失败其余会话也能正常导入。8. 资源占用与性能观察这个项目不跑模型所以不需要关注显存重点看内存和渲染性能。8.1 启动阶段启动本地 Web 服务时内存占用通常只有几十到几百 MB取决于项目框架。因为不需要加载模型权重所以对硬件要求非常友好。8.2 导入阶段导入阶段是 CPU 密集操作要读取 JSONL 文件并结构化解析。几百个会话文件、几万条消息时导入可能需要几十秒到几分钟。这个阶段页面可能出现短暂卡顿属于正常现象。观察方法# macOS / Linux 查看进程资源占用 top -o mem -p $(pgrep -f node|python) # Windows 可以使用任务管理器按内存排序如果导入大量会话时内存持续上涨且不释放说明画布可能一次性渲染了所有节点建议拆分成多次导入。8.3 画布浏览阶段打开包含大量节点的画布时浏览器是关键。现代浏览器对 Canvas/SVG 的渲染能力都不错但如果一次性渲染上万个节点帧率还是会下降。建议优先使用支持节点懒加载或视口裁剪的实现。大批量会话不要一次全铺到画布先缩小范围。关闭不需要的会话分组让视野内节点数量可控。8.4 降低压力的手段如果导入后明显卡顿可以尝试按项目目录分开导入不要一次性把整个用户目录都扫进来。只导入最近 7 天或 30 天的会话。在画布上关闭旧会话的自动展开。给浏览器留足内存关闭多余标签页。9. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后页面打不开端口被占用或服务未启动查看终端日志检查端口监听状态更换端口或重启服务找不到任何会话会话目录路径配置错误用ls确认目录是否存在修正路径或用界面目录选择器某个 JSONL 解析失败文件格式不兼容或损坏打开文件看行内容跳过该文件单独处理Claude Code 和 Codex 会话混在一起来源识别逻辑不完整检查导入时是否区分来源字段更新项目版本或调整配置导入几千条消息后画布卡顿节点渲染数量过大打开浏览器任务管理器看内存和帧率分批导入开启懒加载中文或特殊字符显示乱码编码识别问题查看原始文件是否 UTF-8转换编码后导入浏览器能打开但空白前端资源没有正确加载查看控制台报错清理浏览器缓存重新构建前端端口被占用其他服务占了默认端口lsof -i :3000查看占用进程换端口或杀掉占用进程遇到问题先看日志。这类本地工具的日志通常直接打在终端里报错信息会精确到文件路径和解析行号这是最有效的排查入口。10. 版权、隐私与合规提醒这个项目读取的是 AI 编程工具的本地会话里面可能包含公司内部代码片段、云服务密钥、个人联系方式等敏感信息。使用时有几条原则要遵守默认只在本机运行不要直接暴露到公网。不要把含敏感信息的会话截图直接发到公开平台。如果要把会话整理成文档分享先做脱敏处理替换掉密钥、Token、真实域名等。涉及他人开源代码或公司代码注意版权边界不要用会话内容做超出授权范围的事情。Grok、Claude Code、Codex、OpenCode 生成的代码本身也可能受模型服务条款约束商用前确认合规性。这个项目本身是本地工具不涉及额外的数据上传但“本地安全”不等于“分享安全”。你在画布上整理好的内容一旦导出或截图传播就脱离了原有边界。11. 最佳实践与使用建议如果你确定要长期用这个项目做会话复盘下面这些实践可以少踩很多坑。11.1 定期备份会话目录Claude Code、Codex、OpenCode 的本地目录就是宝贵的上下文资产。建议定期打包备份tar -czf claude-sessions-backup.tar.gz ~/.claude/projects tar -czf codex-sessions-backup.tar.gz ~/.codex/sessions备份文件可以放到外部存储或网盘但要注意加密。11.2 保持小批量导入第一次使用别想着“全量导入”先导入一个项目的会话验证解析效果和画布体验再决定是否扩展。这样做的好处是如果解析有问题影响范围小如果画布卡顿你能快速定位是不是数量问题。11.3 给会话做标签和分组如果项目支持标签或分组建议按项目名、时间范围、技术主题维护一套自己的命名规则。比如project-a / 2025-06 / bug-fix这样画布上不会变成一堆没有语义的节点。11.4 导出前先脱敏画布如果需要导出成图片或文档先检查里面是否出现了密钥、路径、用户名、内部 IP。可以用脚本扫描常见敏感模式import re patterns [ rsk-[A-Za-z0-9_-]{20,}, rapi[_-]?key\s*[:]\s*\S, rpassword\s*[:]\s*\S, ] def scan_text(text: str) - list[str]: hits [] for pattern in patterns: hits.extend(re.findall(pattern, text, re.IGNORECASE)) return hits当然这只是一个辅助工具不能保证完全覆盖所有敏感信息重点还是要靠人工判断。11.5 关注项目更新这类展示项目迭代很快常见做法是先看 GitHub 仓库的 README 和 release notes确认是否支持你关心的新工具版本。如果 OpenCode 或 Grok 更新了会话存储格式本地解析逻辑可能需要跟着更新。12. 总结这个项目最值得尝试的地方是把只会躺在本地的 JSONL 会话变成了真正能“看”的画布。对经常使用 Claude Code、Codex、OpenCode 的人来说它就是本地会话的“可视化档案室”。最先要验证的功能是导入自己最常用的那一个工具的历史会话比如先只导入 Claude Code 的.claude/projects目录确认消息顺序、工具调用、代码片段都能正确显示。再决定要不要把 Codex、OpenCode、Grok 全部接进来。最容易踩的坑有两个一是会话目录路径没配对导致导入结果为空二是大量会话一次性导入后画布卡顿。前者通过ls核对路径可以解决后者用分批导入和懒加载来控制。Grok 的本地会话格式在不同版本间差异较大如果遇到解析为空先确认是否有本地导出能力不要硬等兼容。下一步可以扩展的方向也很多比如给画布增加更多来源工具、把会话按主题自动聚类、导出成 Markdown 报告、或者把接口服务接到自己的复盘工作流里。项目本身不大但解决的是真实存在的“上下文管理”问题值得收藏备用。