为Claude Code和Codex搭建持久化Web终端工作区，让AI编程会话永不断线

最近Vibecoding这个词在开发者圈子里越来越热说白了就是用 Claude Code、Codex 这类终端 Agent 跟着 AI 的节奏快速出活——你给一句粗略需求AI 自己啃代码库、改文件、跑命令你在关键节点把关就行。我在终端里重度用了大半年之后发现一个特别磨人的问题会话说断就断。SSH 一断开、窗口一关之前喂给 AI 的上下文全部丢失第二天接着干又得从头再讲一遍需求。后来我干脆把工作区挪到了浏览器里为 Claude Code 和 Codex 专门搭了一套持久化 Web AI 编码工作区。这篇文章不介绍什么商业产品而是把我搭建这套工作区的设计思路、复现步骤和踩坑记录完整写出来。如果你也同时用多个 CLI 工具、对会话连续性有硬需求或者想把所有 AI 编码任务收进一个统一面板这篇应该能帮上忙。1. 先别急着装Claude Code 和 Codex 到底缺什么1.1 两个 CLI 工具谁干谁的活Claude Code 是 Anthropic 推出的终端 Agent上手之后你会发现它对“理解整个工程”这件事做得极其出色。你让它修一个跨模块的 bug它会先自己顺着调用链找线索把相关文件一个个翻出来改完还会顺手跑一遍测试确认。我实际测试过在不给额外提示的情况下它能独立完成从定位问题到补充注释的完整流程那种“拆解任务后再反馈”的节奏很像一个真人在你旁边干活。Codex 是 OpenAI 的 CLI Agent在代码生成和批量自动化任务上的执行力很强。比如一次性生成十几个配置模板、按规范重构旧接口这类重复性高、规则明确的活Codex 的产出质量相当稳定。新版 Codex 还支持在本地环境中直接执行命令我可以让它读编译日志、自己修正再重试整套流程跑下来基本不用人工干预。两者典型的安装方式都很轻量npm install -g anthropic-ai/claude-code npm install -g openai/codex装完在终端里输入claude或codex就能进入交互界面。如果你只是临时玩一下官方还支持一行命令的免安装试用模式但正式工作我建议还是装全局 CLI因为后面做集成配置会方便很多。1.2 本地终端跑 Agent 的三大痛点CLI 工具本身很强但“终端长驻”这个形态在实际工作中暴露了三个问题。第一是会话上下文不连续。这是最伤人的。Claude Code 的会话上下文默认存在本机的历史文件里理论上可以恢复但因为终端窗口关闭后进程直接被 killclaude --resume的恢复体验并不顺滑经常要从一堆历史列表里翻找。Codex 也类似你重新打开一个会话它不会记得昨天你让它写的那个模块为什么用了这种设计。对于靠 AI 连续工作的人来说每一次断点都是成本。第二是多项目切换成本高。我试着同时维护三个项目就得开三个终端标签页每个里面跑一个独立的 Agent 会话。为了不让它们互相干扰我还要手动记清楚哪个窗口在处理什么需求。时间一长光管理这些终端窗口就已经很累了更别提每个窗口里的上下文还都是割裂的。第三是环境绑定。CLI 装在哪台机器上你就只能在哪台机器上继续干活。我在家里台式机上跑了一半的需求出门以后想在笔记本上继续看进展发现完全接不上。这个体验在如今跨设备办公的大背景下确实有点落后了。那解决问题的思路就很清晰了把终端塞进浏览器让会话跑在一个常驻的 Web 服务里这样不管从哪台设备访问只要浏览器一开就能接上之前的上下文继续干。这就是 Easy Web Vibecoding 这套工作区存在的根本原因。2. Web 工作区的核心设计为什么“持久化”比“好看”重要2.1 浏览器里跑终端Web Terminal 的实现原理在浏览器里跑出一个真终端用的核心组件是 xterm.js 加 WebSocket。简单描述一下这条链路前端用 xterm.js 渲染一个假的终端 UI你敲键盘的时候按键数据通过 WebSocket 发到后端后端在你机器上启动一个真实的伪终端进程通常借助 node-pty 这类库来实现把按键数据喂给它然后把这个进程的输出实时地通过 WebSocket 推回浏览器。对你来说感受就是“在浏览器里看见了终端”实际上所有命令都在本机一个真实的子进程里执行环境变量、路径解析、权限控制和普通终端完全一致。这套结构最棒的一点是Claude Code 和 Codex 本身不需要做任何改动。它们不知道自己在跟 WebSocket 对话只知道标准输入输出还是那一套。也就是说我可以在浏览器里跑原生的 Claude Code而不用等官方出 Web 版。前端页面还可以做得比裸终端更顺手。比如我可以把 Monaco 编辑器接进去让 Agent 生成的代码直接在浏览器里高亮显示我改完一键写回工作目录可以加一个文件树面板查看 Agent 动过哪些文件还可以把多个会话排成标签页像用 IDE 一样管理不同的 AI 编码任务。这些体验是纯终端给不了的。2.2 持久化不只是存日志关键在“断点续接”很多人在自己搞 Web 终端的时候有个误区以为把输出存成日志文件就算持久化了。其实真正的持久化要解决的是“断点续接”——我关掉浏览器第二天打开能不能以最小的成本回到昨天的状态我实测下来的方案是分三层做。第一层是终端内容的落盘。Agent 每次输出、我每次执行的命令都按时间写入对应会话的日志目录。这层成本最低但很有价值因为当我需要回溯“Agent 昨天到底改了什么”的时候直接翻日志比问 Agent 本身要可靠得多。第二层是工作区配置的快照。包括当前项目路径、选择的是 Claude Code 还是 Codex、用哪个模型、环境变量有哪些、系统提示词是什么全部存成一个 JSON 文件。这样重新恢复会话时我能精确还原上次的操作环境而不是靠记忆重新配一遍。第三层是会话 ID 的复用。浏览器端把当前 sessionId 存到 localStorage重新打开页面时直接带着这个 ID 去重新连接后端的伪终端进程。只要那个进程还在运行你就能无缝回到之前的对话现场。后端进程要保证常驻就不能依赖终端本身的生命周期这个服务应该以守护进程的方式独立跑着。2.3 轻量方案和重型 IDE 容器怎么选当时摆在我面前有两条路一是直接搭一套完整云端 IDE比如 Code Server把 VSCode 整个放到浏览器里再在集成终端里跑 Agent二是自己用 xterm.js 写一套轻量 Web 终端把持久化做到自己手里。我试过 Code Server体验确实完整但有一个现实问题太重。在我那台 16G 内存的旧 Mac 上Code Server 空载就要占掉不少内存起几个 Node 服务之后就明显发烫。再加上 Code Server 的权限模型、扩展同步这些都为简单需求引入了不必要的复杂度。而且它默认不提供会话快照能力Agent 上下文丢失的问题还是靠外部脚本补等于把复杂度转移了。轻量方案的优点是启动快、依赖少、完全可控。我把所有逻辑收敛在一个 Node 服务里一个npm run dev就把 Web 端、WebSocket、持久化目录全部拉起来对内存的占用基本可以忽略不计。如果你跟我一样核心诉求是“让 Claude Code 和 Codex 跑得舒服”那就别引入重型 IDE轻量 Web 终端反而是更合适的选择。3. 复现实操从零跑起来自己的 Web 编码工作区3.1 环境准备Node、CLI 一个都不能少开始之前先把底层的依赖理清楚。Node.js 建议装 18 以上版本我用的是 20 LTSNPM 包管理器和整个 Web 终端方案都依赖它。装完检查一下版本node -v npm -v接着安装两个 CLI 工具npm install -g anthropic-ai/claude-code npm install -g openai/codex装完分别验证一下claude --version codex --version到这一步之前你最好先完成各自的登录认证。Claude Code 打开后会引导你走一遍登录授权Codex 需要执行codex login拿凭证。这一步没做好后面 Web 工作区里单独让 Agent 登录会多绕几道弯。3.2 启动工作区接入两个 Agent假设你已经拿到了项目源码目录结构大概是这样easy-web-vibecoding/ package.json src/ server.js # 后端 WebSocket 与持久化逻辑 terminal.js # 伪终端封装 config.js # 会话配置管理 public/ index.html # 前端入口 app.js # 前端交互逻辑启动的顺序很简单npm install npm run dev默认会在本地监听一个端口我习惯设置为 4000 或者 3000。浏览器打开http://localhost:4000你会看到一个极简的界面左边是会话列表右边是终端面板。新建会话时有三项必要配置选择 Agent 类型Claude Code 或者 Codex、填写工作目录路径、选择模型名称。保存之后后端会在这个目录里启动一个伪终端然后自动执行claude或codex你直接在终端面板里交互就行。这里有个细节工作区服务进程要常驻我一般用nohup npm run dev server.log 21 在后台挂着。这样即使关掉 SSH、关掉浏览器后端进程也不会退出下次打开页面直接接上。3.3 把 DeepSeek 接进 Codex / Claude Code很多朋友关心第三方模型接入这确实是个实用话题。以 Codex 官方 CLI 接入 DeepSeek 为例思路是设置 OpenAI 兼容的环境变量export OPENAI_BASE_URLhttps://api.deepseek.com/v1 export OPENAI_API_KEYsk-你的密钥 export OPENAI_MODELdeepseek-chat设置完之后在终端里启动 Codex它会把请求发到 DeepSeek 的接口上去。但这里有个坑我必须写清楚Codex 新版 CLI 内部默认走的是 OpenAI 的/responses端点而很多第三方服务商只提供了 OpenAI 兼容的/chat/completions端点。两者路径不同就会导致请求失败表现常常是“接口报 404”或者模型直接被拒。我在热词里看到的the gpt-5.6-sol model is not supported when using codex with a...这类报错本质上也是模型不匹配的问题——你配置的模型名并不在目标服务商的支持列表里。所以接入 DeepSeek 前先确认你要用的 Codex 版本是否支持自定义端点类型再看目标 API 是否兼容/responses协议。如果不兼容最简单的办法是换用 chat 模式的客户端或者在环境变量里明确指定需要走的标准能力。看到模型名报错时优先检查模型名拼写和该模型是否真的存在然后再想其他原因。Claude Code 接入第三方模型相对要佛系一点它本身对模型选择的限制比较严格。如果你手里有 DeepSeek 的 API更常见的是把 DeepSeek 当代码推理的辅助工具单独用而不是硬塞进 Claude Code 里当默认模型。我个人的判断是第三方模型适合做替补和特定任务日常主力还是用各家的原生模型稳定性和工具调用的完整度更有保障。3.4 持久化在日常使用中应该怎么玩启动完成只是第一步真正顺手的体验来自于持久化功能的日常使用。我给自己定了几个使用习惯。第一所有 Agent 的会话日志目录按月归档放到独立的 NAS 目录里。这样即使本地磁盘清掉缓存我还能通过一份文本把之前的工作现场翻阅回来。第二工作区的会话列表按项目命名我直接以项目名叫会话名。例如一个叫vibecoding-web一个叫>