VSCode Remote SSH 内网服务器使用Codex插件 + Codex跨Provider历史会话迁移完整教程

前言

很多实验室、企业机房服务器处于内网隔离环境，无法直接访问公网，使用VSCode Remote SSH远程开发时，Codex插件联网校验失败、无法正常登录使用；同时更换大模型API服务商（Provider）后，历史Codex会话会在聊天列表消失，无法接续历史对话。本文分为两大模块：借助SSH反向端口转发，复用本机局域网合规代理实现远程服务器Codex联网 、跨Provider迁移恢复历史Codex会话记录，全程不改动服务器全局环境、所有操作可回滚。

第一部分：SSH反向转发｜内网隔离服务器VSCode启用Codex插件

一、问题场景

企业/机房服务器部署在内网网段，受限网络策略无法直连公网，Codex插件联网鉴权报错403；常规在服务器部署代理会修改系统全局环境变量，容易影响同机器其他项目运行。本方案利用SSH反向隧道 ，让远程服务器借用本机已配置好的企业局域网合规代理访问网络，代理仅在SSH连接期间生效，断开连接自动失效，不会污染服务器环境。

示例配置：本机局域网代理服务监听端口7890，若实际使用其他代理端口，全文统一替换端口数字即可。

二、实现原理（SSH RemoteForward反向端口转发）

远程服务器Codex发起网络请求，目标地址指向远程侧127.0.0.1:7890；
SSH服务捕获该端口流量，通过已建立的加密SSH通信链路回传到本地开发电脑；
本机已部署的合规局域网代理处理外网请求，响应数据原路经由SSH隧道回传给远程VSCode；

方案优势：全程流量依托SSH加密传输、无需在远程服务器安装任何代理程序、代理生命周期跟随SSH会话。

三、分步配置

1. 本地VSCode用户代理配置

Ctrl+Shift+P → 打开Preferences: Open User Settings (JSON)，填入配置保存：

json 复制代码

{
  "http.proxy": "http://127.0.0.1:7890",
  "http.proxyStrictSSL": false,
  "http.proxySupport": "on"
}

2. 远程VSCode配置（解决远程配置文件不存在问题）

注意：必须先SSH连上远程服务器，左下角出现绿色SSH连接标识

Ctrl+Shift+P → Preferences: Open Remote Settings (JSON)；
写入配置保存，VSCode自动在远程机器生成Machine/settings.json，无需手动创建目录文件：

json 复制代码

{
  "http.useLocalProxyConfiguration": true
}

配置作用：远程VSCode复用本地配置的代理通道进行网络访问。

3. 本地SSH配置核心（~/.ssh/config）

Windows系统路径：C:\Users\本机用户名\.ssh\config，新增主机配置：

ssh-config 复制代码

Host my-server
    HostName 服务器IP地址
    User 服务器登录用户名
    RemoteForward 7890 127.0.0.1:7890

RemoteForward A B释义：远程机器访问本机A端口，流量转发至本地电脑B地址端口。

四、配置生效步骤

确保本机企业局域网代理服务正常运行，7890端口处于正常监听状态；
全部断开已有SSH连接，重新连接远程服务器（关键，转发规则重连才加载）；
重载VSCode Codex插件，即可正常联网登录。

五、方案优势

零服务器侵入 ：无需安装代理、修改bashrc/全局环境变量；
安全可控：流量走SSH加密隧道传输；
临时生效：SSH断开后远程失去代理通道，不改动服务器原有网络策略。

六、常见踩坑排查

远程找不到settings.json：不用手动mkdir创建，通过Remote Settings(JSON)保存配置后文件自动生成；
依旧403：检查本机局域网代理服务是否启动、本机防火墙放行7890端口、代理白名单放行Codex所需域名；
自定义代理端口 ：全文所有7890统一替换为自身实际使用的代理端口。

第二部分：无缝切换Provider｜Codex历史会话迁移恢复教程

更换API服务商后（如旧api111废弃，改用openai），原有聊天会话因model_provider字段不匹配被隐藏，通过修改会话JSONL与本地SQL索引实现会话无损恢复。

一、前置基础说明

Codex默认会话根目录：$CODEX_HOME/sessions/YYYY/MM/DD/，默认CODEX_HOME=~/.codex；
会话由「会话JSONL文件+state_5.sqlite索引库」共同管理，state_5.sqlite存储线程元数据（provider、会话UUID等）；
会话文件名=会话UUID，JSONL内session_meta.payload.id必须和文件名UUID保持一致。

二、恢复核心三步流程

校验源会话合法性

确认目标会话JSONL文件存在、JSONL每行格式合法，校验首行session_meta.payload.id与会话文件名UUID一致，文件路径处于Codex标准sessions目录。
确认Codex环境目录

查看当前生效CODEX_HOME环境变量，确认会话存储目录，将待恢复会话放到规范路径$CODEX_HOME/sessions/年/月/日/。
跨Provider修改元数据

旧会话绑定失效provider（示例：api111），目标生效provider（示例：openai）：

修改JSONL首行：session_meta.payload.model_provider: "openai"；
修改~/.codex/state_5.sqlite中threads表，id=会话UUID对应model_provider字段同步改为openai；
重启VSCode Codex插件/Codex App，刷新会话列表。

三、会话有效性验证指令

依托Codex内置app-server接口校验，两步核验即代表恢复成功：

thread/list：接口返回列表包含目标会话UUID；
thread/resume：指定UUID执行恢复，会话进入idle就绪状态，插件端正常展示。

四、通用一键恢复Prompt（可直接交给Codex自动执行）

text 复制代码

请只做 Codex 本地会话恢复，不要执行项目任务、不要跑实验、不要调用外部 LLM API、不要 commit/push。

目标：把这个旧 Codex 会话恢复到当前 Codex App 或 VS Code 插件的聊天记录列表中：

<旧会话 jsonl 绝对路径>
<目标 session UUID>

请按以下步骤处理：

1. 检查目标 jsonl 是否存在、属主/权限、文件大小。
2. 逐行解析 JSONL，报告总行数、坏行数、第一条和最后一条摘要。
3. 检查第一条 session_meta.payload.id、cwd、source、originator、model_provider。
4. 确认当前 CODEX_HOME，以及当前 Codex 默认使用的 sessions 目录。
5. 用 codex app-server 的本地协议或等价方式检查：
   - thread/read 是否能按 UUID 读到该会话
   - 默认 thread/list 是否能列出该会话
6. 如果 thread/read 能读到，但默认 thread/list 不显示，并且原因是旧 model_provider 当前不可用，比如 api111：
   - 先备份原 jsonl
   - 先备份 ~/.codex/state_5.sqlite
   - 将 jsonl 第一条 session_meta.payload.model_provider 改成当前可用 provider，例如 openai
   - 将 state_5.sqlite 中对应 threads.id=<UUID> 的 model_provider 同步改成 openai
7. 再次验证：
   - JSONL 仍然合法
   - 默认 thread/list 能看到目标 UUID
   - thread/resume 能恢复该 UUID
8. 最后给我简短结论和回滚路径。

注意：只允许修改该会话 jsonl 和 Codex 本地索引；不要修改项目文件。

五、故障回滚方案（操作可逆）

操作前脚本会自动备份：原文件.jsonl.bak、原始state_5.sqlite备份文件。

需要回滚时：

用.jsonl.bak覆盖替换修改后的会话JSONL；
备份的原始state_5.sqlite覆盖现有索引数据库，即可还原所有配置。

全文总结

内网受限服务器使用Codex：依靠SSH反向转发复用本机企业合规局域网代理，配置轻量化、无环境污染；
Codex历史会话跨服务商迁移：仅修改会话元数据与本地SQL索引，不用重新对话，一键Prompt自动化处理，所有修改支持备份回滚；
两套方案配合使用，完美解决远程开发环境下Codex联网与历史会话留存两大痛点。