局域网离线VibeCoding：Claude Code与Codex内网部署全攻略

如果你和我一样，在一家对数据安全卡得很严的研发团队里工作，每天和“代码能不能出网”“这台机器能不能装客户端”较劲，同时又特别想让 Claude Code 和 Codex 这类 AI 编程工具真正帮上忙，那“局域网离线 VibeCoding”这条路你迟早会走一遍。VibeCoding 这个词现在很火，简单说就是不再把代码当成一句句补全请求喂给编辑器，而是用自然语言描述你想干什么，让 Agent 自己读代码、改文件、跑测试，你只做审查和纠偏。Claude Code 是 Anthropic 官方的终端编程智能体，Codex 是 OpenAI 出品的编码 Agent，两者都能承担跨文件重构、Bug 定位、提交信息生成这类脏活。可问题来了：内网环境往往不允许代码出局域网，开发机不能直连云端，个人订阅配额还经常被组织策略限制。

这篇文章算是我把这两套 CLI 工具在内网里完整跑通之后的复盘，包含架构选型、配置写法、踩坑记录和可以直接抄走的模板。适合那些想把 AI 编程引入团队又不愿意承担数据外发风险的人，也适合个人开发者在本地主机上搭一套纯离线模型服务来体验 Agent 编程。读完你会发现，离线场景下 VibeCoding 不是把体验打折，而是把安全边界和工程可控性一起拿回来。

1. VibeCoding 与两大 CLI 工具：先搞清楚我们在聊什么

1.1 VibeCoding 不是玄学：自然语言驱动的开发流

我第一次听到 VibeCoding 时，以为它指的是“随便说句话，AI 就把整个项目写完”。真正上手之后才明白，这个说法极具误导性。它强调的不是“Vibe”，而是“Coding”：你依然要理解系统架构、知道测试挂在哪个位置、能在 Agent 跑偏时按暂停。区别在于，操作模式从“手工写每一行”变成“用意图驱动 Agent 完成一个完整任务”，比如“把订单模块的缓存策略从 Redis 切到本地内存，并同步更新所有调用点”，然后观察它如何搜索引用、修改文件、执行单测。

在局域网离线环境里，VibeCoding 的价值会被放大。因为代码不离开内网，AI 辅助的整个链路都发生在本地或内部模型中。你不需要担心某个私有算法片段被打包进补全请求传到云端，也不用纠结哪些文件该被排除出上下文。只要有一个能跑起来的本地 LLM 服务，VibeCoding 就能以同样自然的方式工作，而且每次交互产生的过程数据都能沉淀在内网审计系统里。这种“模型可以不够聪明，但数据必须留在自己手里”的取舍，恰恰是很多团队愿意花时间搭离线方案的根本原因。

1.2 Claude Code 与 Codex 的定位差异

很多人问我，Claude Code 和 Codex 到底选哪个。我的答案是有条件就都装，它们不是替代关系，而是互补。

Claude Code 更擅长长上下文与复杂代码库的全局理解。官方客户端支持最高 1M 上下文，适合跨文件重构、历史代码梳理、大模块拆分这类需要“把整个项目装进脑子”的任务。Codex 则偏向执行回路更激进的 Agent 风格，它会主动读仓库、跑命令、根据测试结果自我修正，适合局部功能迭代、快速原型验证和“写完代码顺手跑一遍测试”的工作流。

这里有个常被忽略的点：对局域网部署来说，Claude Code 的ANTHROPIC_BASE_URL设计得比较友好，只要修改环境变量就能把请求指向任意兼容端点；Codex 的自定义 provider 自由度更高，但配置项也更碎，稍不留神就会踩到模型名不匹配的坑。

1.3 离线 VibeCoding 的三个技术前提

想在离线环境里跑通，有三个前提缺一不可。第一，本地要有一台能跑代码模型的推理服务，LM Studio 和 Ollama 是目前最省事的两种。第二，模型网关必须提供 OpenAI 兼容的 HTTP 端点，这样 Claude Code 和 Codex 才能用改 base_url 的方式接入。第三，权限和审计要做在请求入口，不然离线不等于安全，只是把风险从网络层转移到了主机层。

把这三个前提想清楚，后面的配置步骤就顺理成章了：先搭模型服务，再验证 HTTP 端点，最后配置 CLI 指向端点。不要一上来就改环境变量，否则出了问题你很难判断是模型服务没起来，还是 CLI 配置写错了。

2. 局域网离线方案的整体设计：为什么不能直接连云端

2.1 直接连云端 API 的三个现实问题

第一个问题是数据边界。研发阶段的代码往往比上线后的代码更敏感，接口设计文档、未公开的业务规则、临时写死的调试密钥，一旦进入云端补全请求，就成了事实上的数据外发。很多安全团队对 AI 编程工具的要求是“代码不出内网”，这种背景下直接连 Claude 或 OpenAI 的云端 API 基本没有商量余地。

第二个问题是网络与配额稳定性。即使团队允许访问公网，个人订阅也未必经得起连续几小时 Agent 任务的消耗。更麻烦的是，组织策略可能随时在某个环节禁用 Claude Code 的订阅访问，你上次还好好的，第二天一启动就弹“your organization has disabled claude subscription access for claude code”之类的提示，非常影响节奏。与其每次都被这种报错打断，不如把模型接入层放到自己手里。

第三个问题是审计与追溯。使用云端网页交互，操作留痕往往是黑盒。而内网统一网关可以在入口处记录每次请求的模型、时间、token 消耗和提示词摘要，方便安全合规部门快速复核。我接触过的不少项目组，最终决定走离线方案，并不是因为买不起云 API，而是为了把 AI 编程纳入可管控的工程流程。

2.2 内网模型网关：CLI 工具到 LLM 之间的桥

我推荐的架构很简洁：

Claude Code / Codex -> 本机或局域网模型网关 -> 本地 LLM（LM Studio / Ollama）

这里的“模型网关”不是用来访问什么特殊网络的服务，而是一个本地程序，它接收 Claude Code 或 Codex 发来的标准 HTTP 请求，再翻译成实际 LLM 推理服务能理解的格式。最省事的方式是让 LM Studio 和 Ollama 直接暴露 OpenAI 兼容端点，CLI 工具把base_url指向这个端点即可。

为什么要一个独立的网关层，而不是让每个开发者都直连本地推理进程？有三个原因。第一，开发机上跑大模型不是长久之计，团队一般会把模型服务集中到一台大内存服务器上。第二，统一网关可以做模型名映射，不用在每台电脑上改模型 ID，模型升级时只动网关配置。第三，网关层能夹带额外的审计和路由逻辑，比如“只有白名单目录下的代码才允许进入外部模型”，这比在每台开发机的 CLI 配置里各写一条规则可靠得多。

这里需要明确：离线指的是代码资产不经过公网，并不是说局域网内部不能传输模型请求。LM Studio 默认绑定本地回环地址，如果要在团队内共用，需要把服务监听地址改成内网 IP，并做好防火墙与 key 校验。这一步往往被忽略，结果网关端口暴露在办公网络里，被同事无意间扫到都会造成麻烦。

3. 工具选型解析：CC Switch 与模型网关怎么选

3.1 CC Switch：多供应商切换的得力助手

CC Switch 在最近的讨论里热度很高，尤其是“cc switch local proxy failed while handling codex endpoint /responses”这类报错，几乎每个自建网关的人都会撞到。CC Switch 是什么？它是一款面向 Claude Code / Codex / Gemini CLI 的模型供应商切换工具，底层思路是在本机启动一个转发服务，把 CLI 的请求拦截下来，再转发到 DeepSeek、Qwen、GLM、本地 LM Studio 等不同后端。

如果你只是在单台开发机上折腾，CC Switch 确实方便：装好它，选一个供应商模板，填上 API Key，它自动帮你改写 Claude Code / Codex 的环境变量。但对团队内网部署来说，我建议把它当成“单机调试工具”，而不是生产依赖。原因很简单：CC Switch 的本地转发服务会占用一个端口，所有流量都要先到这台机器再出去，一旦进程挂掉，所有 Agent 任务都会报连接失败；而独立网关可以由 systemd 托管，挂了自动重启，稳定性高得多。

如果你依然选择在团队里用 CC Switch，请重点检查版本。旧版本对 Codex 的 Responses API 路径支持不完整，经常出现“/responses 端点处理失败”的报错。新版对wire_api的处理更接近官方，但仍然建议先用 curl 手动验证一次转发链路，确认 CLI 请求确实到了目标模型服务。

3.2 本地模型网关：LM Studio 与 Ollama 的取舍

在局域网离线场景里，最主流的本地推理方案是 LM Studio 和 Ollama。LM Studio 的优势是图形化操作、模型下载与管理一体化，内置 OpenAI 兼容服务器，开箱即用。Ollama 的优势是命令行友好、支持量化模型规格灵活，而且它的/v1兼容端点也是标准的 OpenAI 风格。

对 Claude Code 来说，两者都可行，只要把ANTHROPIC_BASE_URL指向对应端口即可。对 Codex 来说，重点在于wire_api：Codex 默认使用 OpenAI Responses API，而 LM Studio / Ollama 主要实现 Chat Completions API，所以你必须在config.toml的 provider 里显式写wire_api = "chat"，否则会得到一大堆 HTTP 400。

选型建议：如果内网服务器是 Windows 且团队不想折腾命令行，直接上 LM Studio；如果更习惯 Linux + systemd + shell，Ollama 更顺手。模型层面，代码类任务优先挑通用代码模型，比如 Qwen2.5-Coder、DeepSeek-Coder-V2、GLM-4 的本地权重版本。需要说明的是，通过第三方 API 接入 DeepSeek、Qwen、GLM 是另一条路径，和纯离线不冲突，但我们这里先讲本地权重，因为“离线”才是安全兜底。

4. 完整实操：在局域网内把 Claude Code / Codex 跑起来

4.1 准备阶段：安装 CLI 工具与依赖

先说安装。Claude Code 通过 npm 分发，要求 Node.js 18 以上。在内网环境里，你需要先在一台有 npm 包缓存或内部 npm 镜像的机器上准备好离线包，再把 tarball 拷贝到开发机，用类似npm install -g /path/to/claude-code.tgz的方式完成全局安装。如果团队允许访问企业 npm 仓库，也可以直接把 registry 配成内部源，省去手动拷贝。

Codex CLI 的安装类似，官方包名是@openai/codex。安装完成后，先跑一次codex --version确认路径无误。Codex 在启动时会尝试从 OpenAI 登录态或 key 读取凭证，但我们后面会通过自定义 provider 绕开这套登录流程，所以第一轮报“登录失败”不用慌，继续往下配置就好。

这个阶段最容易出错的，是忘记检查 Node 版本。Claude Code 对 Node 版本很敏感，低于 18 会出现各种奇怪的 TLS 报错。建议统一用 nvm 锁到 Node 20 LTS，减少后续排查成本。如果团队内有多台开发机，最好把 Node 版本也纳入统一基线，不要一台 18 一台 22，否则同一个配置在这台机器能用，换一台机器就莫名其妙失败。

4.2 配置 Claude Code 接入本地模型

Claude Code 接入本地模型的原理，是让官方 CLI 以为自己正在和 Anthropic API 通信，实际地址被环境变量替换成内网网关。典型写法：

export ANTHROPIC_BASE_URL="http://127.0.0.1:1234/v1" export ANTHROPIC_AUTH_TOKEN="local-model-token" export ANTHROPIC_MODEL="qwen2.5-coder:32b" export ANTHROPIC_SMALL_FAST_MODEL="qwen2.5-coder:14b" export ANTHROPIC_DEFAULT_SONNET_MODEL="qwen2.5-coder:32b" export ANTHROPIC_DEFAULT_HAIKU_MODEL="qwen2.5-coder:14b"

注意，ANTHROPIC_AUTH_TOKEN在本地网关场景下随便填一个非空字符串即可。LM Studio 默认不校验 token，但如果你的网关加了鉴权，就需要填真实密钥。ANTHROPIC_SMALL_FAST_MODEL对应 Claude Code 内部用来处理标题、摘要等轻量任务的模型，如果本地显存不够同时跑两个完整模型，可以把它指向更小的量化版本，避免 OOM。

如果想把配置写进settings.json，通常放在~/.claude/settings.json。一个适合内网的最小配置长这样：

{ "env": { "ANTHROPIC_BASE_URL": "http://127.0.0.1:1234/v1", "ANTHROPIC_AUTH_TOKEN": "local-model-token", "ANTHROPIC_MODEL": "qwen2.5-coder:32b", "ANTHROPIC_SMALL_FAST_MODEL": "qwen2.5-coder:14b" }, "permissions": { "allow": ["Bash", "Read", "Edit", "Write"], "deny": ["Web", "WebSearch"] } }

这里有个实用技巧：permissions.deny里写Web可以直接禁掉 Claude Code 的网页搜索功能。对离线环境来说，网页搜索既用不到，又是潜在的数据外流点，提前禁掉比每次登录后手动拒绝省心。很多团队做安全审计时，会专门检查这一项配置。

4.3 配置 Codex 接入兼容模型

Codex 的配置统一放在~/.codex/config.toml。要让 Codex 走本地网关，需要自定义 model provider。最小示例：

model = "qwen2.5-coder:32b" model_provider = "local" [model_providers.local] name = "Local LLM Gateway" base_url = "http://127.0.0.1:1234/v1" env_key = "LOCAL_API_KEY" wire_api = "chat"

env_key指定了从环境变量里读 API key 的名字。本地网关可能不需要 key，但你仍然要保证这个环境变量存在，否则 Codex 可能直接退出。可以先执行export LOCAL_API_KEY="local-model-token"再启动。

很多人在这一步卡住，是因为 Codex 的新版本里还有experimental_use_rmcp_server之类的参数。但我建议先把最基础的四行配好，跑通一次codex "帮我看看当前目录下的 README 有什么问题"，再去调整高级选项。Codex 的沙箱执行体验不错，但本地模型在工具调用上的稳定性参差不齐，如果出现“调用工具后模型没有继续回复”的情况，先怀疑网关的上下文长度设置，而不是怪 Codex。

4.4 验证链路：先用 curl 再进 CLI

配置完成后，不要急着打开 CLI。先用 curl 验证整条链路是最稳妥的做法。以 LM Studio 为例：

curl http://127.0.0.1:1234/v1/models

这一步能看到网关暴露的模型列表和真实模型 ID。然后再模拟一次对话请求：

curl http://127.0.0.1:1234/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5-coder:32b", "messages": [{"role": "user", "content": "ping"}] }'

如果返回正常，说明网关没问题，再去改 CLI 配置。如果这一层都不通，就别浪费时间调 Claude Code 和 Codex 了，先把模型服务恢复起来再说。这个简单的排查顺序，能帮你省下不少“为什么 CLI 突然报错”的时间。

5. 关键配置与参数详解：不踩坑的配置写法

5.1 Claude Code 的 settings.json 常见参数

Claude Code 的配置字段很多，我只说长期内网部署用得上的几个。

permissions.allow和permissions.deny控制 Agent 能执行的工具范围。我通常只放行Bash、Read、Edit、Write，拒绝Web和WebSearch。模型相关字段里，除了上面提到的，还有一个forceLoginMethod要注意：断网环境下如果配置成"oauth"，会导致每次启动都卡在登录页，建议完全不要设置这个字段，让 CLI 直接读取环境变量。

还有apiKeyHelper字段，很多教程推荐用它切换 key，但对内网网关反而增加了复杂度。我们用的 token 是固定的，直接export到.bashrc或.zshrc，简单直接，不容易被误改。最后是各种新特性开关，比如includeCohere，我建议全部保持默认，不折腾。

5.2 Codex 的 config.toml 参数详解

Codex 配置中，model_provider和wire_api是两个最关键参数。wire_api一共两种取值："responses"和"chat"。默认值是"responses"，对应 OpenAI Responses API 的/responses路径；当你指向 LM Studio / Ollama 时，必须改成"chat"，否则网关找不到路径。

另一个重要参数是model。Codex 的模型名对 provider 很敏感，如果你在model里写了qwen2.5-coder:32b，但网关后端实际暴露的名字是qwen2.5-coder-32b（中间是横线），就会报 “model is not supported”。解决方案是在网关层配置模型别名，或者直接改 Codex 配置里的大小写和分隔符。出错时先用 curl 打一次网关的/v1/models接口，拿到真实模型 ID，再回填到配置。

5.3 内网共享网关：团队共用一套模型服务

当团队超过三个人以后，把 LM Studio 安装在某个同事的开发机上并不合适。更好的做法是在内网服务器上跑一个常驻网关。以 Ollama 为例，启动前设置OLLAMA_HOST=0.0.0.0，让服务监听所有内网网卡，然后把端口11434在防火墙中限定为公司网段。客户端的 base_url 写http://192.168.1.10:11434/v1。

为了安全，务必在网关入口加一层简单鉴权。Ollama 本身不提供 key 校验，可以在最前面加一层 Nginx，利用它的配置做请求头校验；或者使用 LM Studio 自带的 API key 字段。这样即使有人不小心把端口暴露到非办公网络，也能挡住未授权访问。团队里每位开发者的 CLI 配置里保持ANTHROPIC_BASE_URL和 Codexbase_url一致，模型 ID 由网关统一映射。换模型时只改网关，不需要全员改配置。

6. 常见问题与排查技巧实录

6.1 Codex 请求在网关层返回 404 或 405

这是离线下最常见的问题。现象是 Codex 启动后，Agent 正准备执行任务，网关日志里出现针对/responses路径的 404。原因就是前面提到的wire_api没有改成"chat"。排查路径：先看网关日志，确认实际收到的路径；再打开~/.codex/config.toml，检查 provider 里的wire_api；如果已经改了，检查 Codex 版本，旧版本有时候不读取这个字段，需要升级。升级后如果还出现类似问题，手动用 curl 模拟一次请求，定位是路径问题还是模型名问题。

6.2 CC Switch 本机转发服务报错

CC Switch 在处理 Codex 的 Responses 类请求时，如果版本较旧，会在本地转发环节直接失败，现象是本机转发模块返回失败，日志里有一串和转发服务有关的报错提示。这个问题通常不是模型问题，而是 CC Switch 内置转发逻辑不支持 Codex 新的请求格式。解决办法有三条路：升级 CC Switch 到最新版；换掉 CC Switch，直接用 config.toml 指向网关；或者在 CC Switch 里选择“Codex chat 兼容”模板。我最后是把 CC Switch 从生产链路里撤掉了，只在单机调试模型时用，因为它的日志太简略，内网排障成本高。

6.3 组织策略禁用了 Claude Code 订阅访问

“your organization has disabled claude subscription access for claude code”这个报错，本质上是 Claude 账号在组织侧被限制了订阅权限，跟 CLI 配置无关。如果你在内网，又必须用 Claude Code 完成工作，最靠谱的办法不是和报错较劲，而是直接把模型流量切换到自己的本地网关。设置好ANTHROPIC_BASE_URL后，CLI 不再依赖官方的订阅权限校验，报错自然消失。当然，这要求你使用的模型权重或第三方 API 授权是合规的，本地模型不涉及这个问题。

6.4 模型上下文窗口不够导致任务中断

本地模型普遍支持 8K 到 128K 上下文，和 Claude Code 的 1M 大上下文差距明显。当你让它分析一个大型仓库时，常出现“上下文超限”的报错。这时需要反推处理：把大任务拆成小任务，用 Agent 的子代理机制只加载相关目录；调低ANTHROPIC_SMALL_FAST_MODEL的上下文需求；或者在网关层把最大生成 token 数调大。如果你手头有超大上下文版本的模型资源，部署到内网服务器后，Claude Code 的长上下文体验会更接近原版 API。

6.5 Codex 登录不上、无法加载组织设置

Codex 登录不上，一半是网络策略问题，一半是配置缓存问题。在内网环境里，Codex 原本要连 OpenAI 的登录端点，如果这个域名不可达，就会出现“登录不上”的现象。我们的做法是跳过官方登录，直接用自定义 provider，这样根本不需要登录。如果已经配置过自定义 provider 但仍然提示登录，检查~/.codex下有没有残留的 auth 配置，备份后删掉再试。另一个常见原因是系统时间不对，导致 token 校验失败，这个问题在内网机器上并不少见。

7. 实操心得与内网部署的进阶建议

7.1 我在实际部署中踩过的坑

第一坑是太迷信大模型。第一次跑通 Claude Code 接本地模型时，我用了 7B 量化模型，让它做一个跨 20 个文件的接口重构，结果它每一步都在自我怀疑，改到一半把逻辑写横了。后来把模型换到 32B 级别，效果立刻稳定。所以，离线 VibeCoding 的瓶颈往往不是工具配置，而是本地模型的推理能力。建议代码生成至少用 14B 以上，分析任务优先 32B，如果你的服务器显卡足够，直接上 70B 级别，体验会有质的提升。

第二坑是网关的并发。全团队共用一台 64G 内存的服务器时，如果四个人同时跑长任务，显存和内存很容易被打满。后来我们在网关层加了简单的并发控制，限制同一时间进入推理服务的任务数量，并监控模型加载数量。不要试图让一个内存即将溢出的推理服务同时服务所有人，那会让每个人都觉得 AI 变笨了。实际上，调优后的并发策略是：允许 2 个长任务并行，更多请求排队。

7.2 画好数据边界：外部模型与本地模型的分工

在必须使用第三方模型 API 的场景下，我建议在网关上做路由规则。例如，.env、密钥文件、合同相关代码目录，只允许走本地模型；而公开的开源项目、组件示例、测试代码可以走合规的云端 API。这个规则可以用网关层的目录前缀判断实现，也可以用 Claude Code 的权限系统先拦一道。数据边界的核心原则是：宁可让模型少看一点代码，也不能让敏感字段进入外部服务。内网环境里，合规比效率重要，这不是一句口号，而是每一次请求日志里都能看出来的选择。

7.3 演进方向：把内网 VibeCoding 变成团队基础设施

当一个人跑通以后，你可以把整套配置做成镜像或配置模板。比如用 Ansible 一键下发settings.json、config.toml、环境变量和 Node 版本；或者制作一个内网镜像，包含 Claude Code 和 Codex 的离线安装包。下一步还可以接入 RAG，把团队内部设计文档、历史故障总结放进来，让 Agent 在改代码前先检索项目背景。这能显著提升本地模型在专有业务上的表现，也让 AI 编程真正从“体验”变成“基础设施”。

我个人体会最深的，不是“能不能跑通”，而是“跑通之后你是否愿意把 AI 写入日常开发流程”。在局域网离线环境下，Claude Code 和 Codex 给我的感觉更像一个随时可以叫停的实习生：快速、不越界、可控。如果你也在搭类似环境，最后再分享一个小技巧：把网关的审计日志打开，每周花十分钟看一次“哪些目录被喂给了外部模型、哪些任务在高频重试”，持续优化数据边界和模型选型。内网 VibeCoding 不是把云端能力搬进局域网，而是让 AI 辅助在安全边界内变成真正可依赖的研发基础设施。