正想聊聊 VibeCoding 这波趋势身边越来越多同事开始在终端里用 Claude Code、Codex 这类命令行的 AI 开发工具。工具确实好用但一提“局域网离线”四个字很多人第一反应就是“那还能用吗”。答案是能而且值得认真配置好。我这段时间在完全没外网出口的企业内网里把 Claude Code 和 Codex 都跑起来了代码全程不出内网请求全部落在局域网模型服务上。这篇就是我的完整落地记录从离线安装讲到报错排查适合内网开发者、有数据保密要求的项目组以及想把 VibeCoding 带到隔离网络里的工程师。1. 先搞明白 VibeCoding 是什么以及为什么非要在局域网里跑1.1 VibeCoding 的底层逻辑从“写代码”到“聊代码”VibeCoding 这个说法核心不是某个具体工具而是一种全新的编码姿势你用自然语言描述需求、报错、重构意图AI 在你授权范围内直接改代码、执行命令、跑测试然后你把结果 review 一遍合入版本库。Claude Code 和 Codex 就是这种模式的代表性 CLI 工具它们跑在终端里比 IDE 插件更主动能自主完成“读代码—定位问题—改文件—运行验证”的闭环。我自己的感受是它把很大一部分“搬砖”工作外包给了模型重构一个模块、补齐单元测试、排查一个晦涩的报错你只需要把上下文和约束说清楚剩下的交给模型迭代。传统补全工具是“你说一句它补一行”VibeCoding 是“你说目标它交出差量”。这类工具的共同点是需要一个高质量的模型服务。默认配置下Claude Code 会连 Anthropic 的云端接口Codex 会连 OpenAI 的云端接口。在办公网络环境里这套默认链路通常走不通而且就算走得通公司的代码片段被发送到外部服务这件事本身就有合规风险。于是“局域网离线”就不是一个可选项而是硬约束。1.2 离线和内网环境里到底缺什么、要补什么先盘点一下真实痛点。第一很多企业的研发网段根本没有外网出口npm、GitHub、云 API 全都不可达连装个包都得想办法第二代码资产是核心机密研发过程中的临时文件、会话记录、diff 内容都不允许离开内网第三团队需要一个统一的模型入口不能每个人各自连外面的服务既不好管控也没法记账审计。这就有点像在家里点外卖和自家开灶的区别。外卖方便但你的口味偏好、地址、甚至菜品照片都经过了外部平台自家开灶只要备好食材模型权重、锅铲推理服务和菜谱提示词工程就能在自家厨房里做出一桌菜。局域网离线方案的本质就是把“厨房”搬进内网。要补的东西有四个模型推理服务本身、一个兼容 Claude/OpenAI 接口的请求转发层、离线可用的安装源以及一套令牌和日志管理机制。下面我把每一步怎么落地都拆开来讲清楚。2. 离线环境先把工具装好Node.js、Claude Code、Codex2.1 解决 Node.js 和 npm 的离线安装与内网镜像Claude Code 和 Codex 都是基于 Node.js 的 CLI 工具所以第一步是准备一个干净的 Node.js 运行时。这里不建议用系统包管理器装因为离线环境下 apt 或 yum 的源未必可用我推荐直接下载官方 tar.xz 源码包进内网后解压即用。先在有网络的机器上下载 Node.js 20 LTS 的 linux-x64 tar.xz比如 node-v20.12.2-linux-x64.tar.xz拷进内网后执行sudo mkdir -p /opt/node sudo tar -xJf node-v20.12.2-linux-x64.tar.xz -C /opt/node --strip-components1然后把路径写进 /etc/profile.d/node.sh让所有用户都能直接用export PATH/opt/node/bin:$PATH验证一下node -v npm -v正常情况下会输出 v20.12.2 和对应的 npm 版本。如果内网有自建的 npm 镜像比如 Verdaccio、Nexus记得把 registry 指过去后面装全局包会顺畅很多npm config set registry http://你的镜像地址/repository/npm-public/如果没有内网镜像也别慌可以在外网机器上用npm pack把需要安装的包打成 tgz再拷进内网npm install -g。这个方法对任何 npm 包都通用唯一的坑是依赖树大的包要记得把依赖也一并打全。我通常的做法是在外面干净的目录里先完整装一次再用npm shrinkwrap锁定依赖之后打包带走。2.2 安装 Claude Code 和 Codex并确认版本可用Node.js 就绪后安装就简单了。Claude Code 的 npm 包名是anthropic-ai/claude-codeCodex 的包名是openai/codex。如果有内网镜像直接全局安装npm install -g anthropic-ai/claude-code npm install -g openai/codex装完验证版本claude --version codex --version这里要提醒三个离线安装常见的坑。第一个是 Node 版本太低两个工具都对 Node 版本有最低要求至少 18建议直接上 20。第二个是权限问题如果在全局目录没有写权限会报 EACCES要么用 sudo 装要么把 npm 的全局 prefix 指到用户目录。第三个是“装完了但命令找不到”Linux 下多半是 PATH 没包含全局 bin 目录检查一下/opt/node/bin或者~/.npm-global/bin是否在 PATH 里。如果内网连 npm 镜像都没有就走离线包路线。我的操作流程是在外网机器上npm pack anthropic-ai/claude-code得到 tgz 文件如果工具依赖原生二进制有些新版会在 postinstall 阶段下载二进制需要格外小心因为离线时 postinstall 会失败。这时候优先找已经编译好的 release 包或者在有网络的同架构机器上装好之后把整个 node 全局目录打包拷进去。实测下来同发行版同架构之间拷贝/opt/node下的 lib/node_modules 基本能跑但偶尔会遇到 glibc 版本不一致的问题最保险的还是目标机器上重新安装一遍。3. 把模型请求从云端切到局域网核心配置拆解3.1 Claude Code 的请求地址与令牌配置绕不开环境变量Claude Code 默认会把请求发到 Anthropic 官方 API但它的设计比较周到提供了两个关键环境变量来覆盖请求地址和身份验证信息ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN。只要设置了这两个变量所有请求都会走你指定的端点令牌也由你说了算。我推荐的配置方式不是写在 shell 配置文件里而是单独写一个环境文件比如/etc/cc-env.sh内容是export ANTHROPIC_BASE_URLhttp://你的局域网模型服务IP:8000/anthropic export ANTHROPIC_AUTH_TOKEN你的内网令牌 export ANTHROPIC_MODELqwen2.5-coder:32b export ANTHROPIC_SYSTEM_PROMPT你自己定制的系统提示词 export ANTHROPIC_LOG/data/cc-logs/claude.log然后在启动 Claude Code 之前source /etc/cc-env.sh再执行claude。之所以不写死在~/.bashrc里是因为同一台机器有时候也要跑公共云场景环境隔离更干净。除了环境变量Claude Code 也支持在~/.claude/settings.json里配置模型选项。比如我想让每次会话默认使用指定模型就在这里写{ model: qwen2.5-coder:32b, env: { ANTHROPIC_AUTH_TOKEN: 你的内网令牌 } }注意一点如果环境变量和配置文件里的值冲突环境变量的优先级更高。我会把不敏感的设置放在 settings.json 里方便团队统一敏感令牌则通过环境变量注入避免放进版本库。3.2 Codex 的供应商与模型配置Codex 的思路类似但配置结构更偏向“多供应商”模式。它支持 OpenAI 兼容协议而OPENAI_BASE_URL和OPENAI_API_KEY就是最基础的切流开关export OPENAI_BASE_URLhttp://你的局域网模型服务IP:8000/v1 export OPENAI_API_KEY你的内网令牌 export OPENAI_MODELdeepseek-chat需要注意 Codex 有两种接口形态。一种走/v1/chat/completions兼容大多数 OpenAI 代理程序另一种走较新的/v1/responses接口部分局域网服务端不一定实现。如果请求时遇到“endpoint 不支持”一类的问题优先检查是不是OPENAI_BASE_URL指到的服务端实现了对应的端点。多数情况下我会把服务端实现成同时暴露/v1/chat/completions和/v1/responses两个路径保证两个工具都能用。Codex 还支持在配置文件~/.codex/config.toml里声明model_providers通过自定义供应商来绑定多个模型地址[model_providers.internal] name internal base_url http://你的局域网模型服务IP:8000/v1 api_key_env_var OPENAI_API_KEY wire_api chat然后在[model]段里指定供应商对应的模型model internal/deepseek-chat这种写法的好处是团队可以维护一份标准 config每个人只改自己的 api_key模型切换通过版本库更新配置即可。3.3 一个能跑的局域网模型服务示例Ollama Qwen 系列前面讲的是客户端怎么切下面说说局域网里的模型服务端。最常见的快速方案是 Ollama它在离线环境下的部署成本极低单二进制、自带模型管理、默认支持 OpenAI 兼容接口。在局域网服务器上装好 Ollama启动前设置监听地址让它不要只绑定回环地址export OLLAMA_HOST0.0.0.0:11434 ollama serve然后在同网段的机器上验证服务是否可达curl http://局域网服务器IP:11434/api/tags能返回模型列表 JSON说明服务通了。接下来拉取代码模型。Ollama 官方的代码模型里我常用qwen2.5-coder系列有 7B、14B、32B 等多种规格。完全离线的网络可以通过在有外网的机器上ollama pull qwen2.5-coder:14b然后导出模型文件拷进内网后ollama create导入。但 Claude Code 默认发的是 Anthropic 风格请求Ollama 原生只提供 OpenAI 兼容接口中间还差一个“翻译”环节。我的做法是在内网服务器上部署一个请求流转网关比如 claude-code-router把 Anthropic 的/v1/messages请求翻译成 OpenAI/本地模型能理解的/v1/chat/completions。配置大概长这样{ provider: ollama, ollama: { base_url: http://127.0.0.1:11434, model: qwen2.5-coder:14b } }网关启动后监听 8000 端口对外暴露/anthropic路径Claude Code 的ANTHROPIC_BASE_URL指向它即可。Codex 更省事直接指到 Ollama 或者网关的/v1路径就能跑。如果内网允许访问特定的模型供应商 API比如通过合规审批的 DeepSeek 开放接口也可以直接把ANTHROPIC_BASE_URL指到供应商的 Anthropic 兼容端点。需要注意供应商提供的模型名必须和客户端填写的一致否则后面会出现“model is not supported”的报错这一点往下看。4. 高频报错与排查实录4.1 “auth token is unavailable” 这类认证问题怎么破在离线内网环境里Codex 很容易在启动时直接报出codex auth token is unavailable。这通常意味着 CLI 找不到可用的身份令牌。默认情况下Codex 会尝试交互式登录登录流程需要浏览器而内网机器既没有外网、也没有配置好的浏览器环境自然拿不到令牌。我的解决思路是绕开交互式登录直接用环境变量注入令牌。启动前明确设置OPENAI_API_KEY并确认~/.codex/auth.json不存在或至少不是过期的空文件。因为 Codex 的优先级逻辑里本地 auth 文件往往优先于环境变量一旦 auth.json 存在且无效会直接遮挡环境变量配置。实际操作时我习惯这么处理unset OPENAI_API_KEY # 先清理可能冲突的历史变量 export OPENAI_API_KEY你的内网令牌 codex --version如果还是不行就删除本机残留的~/.codex/auth.json再试。团队里我建议统一把令牌放在环境配置文件里通过部署脚本下发避免每个人手动管理。另一个容易被忽略的问题是令牌里如果带有特殊字符记得用单引号括起来否则 shell 会做变量展开导致最终请求头里的令牌和预期不一致。4.2 “model is not supported” 与“模型名对不上”的坑我在配置 Codex 接入局域网模型时遇到过一条很典型的报错the gpt-5.6-sol model is not supported when using codex with ...这行报错看起来像是服务端拒绝模型但真正原因往往是客户端用了默认的模型名而默认模型名只在官方的模型列表里存在。你服务端跑的是 DeepSeek 或 Qwen客户端填的却是 GPT 系列那自然不匹配。排查分三步。第一步用 curl 直接请求模型服务确认服务端支持的模型名列表。第二步在配置里把model改成列表里的准确名称。第三步检查有没有写透传模型名的格式比如 Codex 的vendor/model格式或者网关里的模型映射表。Claude Code 这边的相似问题是claude启动时默认找claude-*模型如果没有在 settings.json 或环境变量里覆盖ANTHROPIC_MODEL就会请求一个局域网服务根本不认识的模型名。这个问题在我接 Ollama 时反复出现最后统一在网关层做了模型名映射无论客户端传什么名字网关都把它替换成后端实际存在的模型。这样做的好处是团队成员的客户端配置可以完全统一服务端升级模型时只需改网关映射。4.3 本地转发服务连接异常的问题很多人在配置局域网环境时遇到过类似cc switch local proxy failed while handling codex endpoint这样的报错。我先说明一下这行错误信息是提示“本地转发服务在处理 Codex 请求时连接失败”而不是说你不能这么用。它的本质是客户端把请求交给了本机或局域网内的某个转发进程但那个进程没有正常响应。我排查这类问题固定按三步走。第一确认转发进程真的在监听端口。用ss -lntp | grep 8000看端口是否 LISTEN很多时候是服务没启动、或者启动后崩了。第二用 curl 测端点是否可通比如curl http://127.0.0.1:8000/v1/models如果 curl 都超时说明问题出在服务本身而不是客户端配置。第三检查证书策略。如果转发服务用了自签发证书而 CLI 默认强制校验 TLS就会在握手阶段失败表现为“连接失败”或“证书错误”。我自己的处理是给转发服务配置内部受信任的证书或者让客户端明确跳过 TLS 校验。还有一个内网特有的坑是监听地址写错。很多人把服务绑定在127.0.0.1然后客户端配置里写的是局域网 IP流量压根到不了服务。记住只在本机用就写 127.0.0.1要让同网段其他机器访问就是0.0.0.0或具体内网 IP。4.4 一张速查表把高频报错一次说清我把这段时间遇到的典型问题整理成了速查表方便大家对照处理。现象常见原因处理方式codex auth token is unavailable无浏览器登录态auth.json 残留设置 OPENAI_API_KEY清理 ~/.codex/auth.json确保环境变量优先级生效model is not supported模型名和实际服务端不匹配用 curl 查询模型列表统一改写客户端 model 配置在网关做模型名映射local proxy failed / 请求超时转发服务未启动监听地址错误TLS 证书不受信任检查端口监听用 curl 验证端点正确绑定 0.0.0.0配置内部证书或跳过校验npm install 时 getaddrinfo 失败离线环境 npm 未指向内网镜像配置内网 registry或使用 npm pack 离线安装启动后命令找不到PATH 未包含全局 bin 目录检查 /opt/node/bin 或 ~/.npm-global/bin 是否加入 PATH请求到达服务但返回 404服务端没有实现对应端点路径确认是否支持 /v1/chat/completions 或 /v1/responses检查网关路由配置这张表没有覆盖所有极端情况但内网环境里 80% 的问题都集中在认证、模型名、网络路径这三类。我一般建议在做任何复杂配置前先用 curl 把链路打通再上 CLI能少踩很多坑。5. 局域网离线下我用下来最顺手的几步走法5.1 我建议的落地顺序按这个来基本不折腾第一次搞这套东西最容易犯的错是先把 CLI 装好、把环境变量配好然后去连一个还没部署的模型服务最后面对一堆报错不知道是服务的问题还是客户端的问题。所以我的建议是严格按“服务端 → 验证链路 → 客户端 → 联调”的顺序来做。第一步先把局域网里的模型服务跑起来确认curl能拿到模型列表。第二步用一条最简单的非流式请求测试模型推理比如让模型返回一句“你好”确认输出正常。第三步把网关或转发层部署好再 curl 一遍网关的端点确认翻译后的请求能打到后端模型。第四步才安装配置 Claude Code 和 Codex。第五步用最小命令比如claude print hello验证确认通了再放开做真实任务。这个顺序能保证任何一步出问题你都能明确知道瓶颈在哪一层。我团队里入职的新同事按这个顺序操作最慢的也能在半小时内跑通。5.2 局域网不是绝对安全令牌和日志同样要管好很多人觉得“没有外网”就等于“绝对安全”这是错觉。内网也有横向渗透的风险而且多人共享一台模型服务时令牌如果不分权限任何一个开发者的令牌泄露都会影响整个团队。我的做法是模型服务用一个专用系统账号运行不给任何交互式 shell 权限每个团队成员分配单独的令牌服务端做最小权限映射不允许跨令牌访问其他目录。日志管理同样不能忽略。Claude Code 和 Codex 都会在本地保留会话记录里面可能包含代码片段。我在企业里会强制设置日志路径到一个统一目录并开启定期清理任务。同时提醒团队成员不要在 AI 会话里粘贴密钥、密码等敏感信息这条我会写进团队的约定文档里。最后内网服务尽量绑定在专门的研发网段不要直接暴露在办公网或访客网段必要时用 iptables 做来源 IP 限制。5.3 从命令行到桌面版、编辑器的扩展CLI 跑通之后还可以往周边扩展。VSCode 里可以通过终端面板内嵌运行 Claude Code 或 Codex体验上接近 IDE 插件但能力仍然是 CLI 的完整形态。桌面版Claude Code Desktop在有外网的环境下用得很火但在内网环境我更推荐直接用claude命令配合 tmux 使用少一层壳就少一份配置复杂度。另外如果你们团队平时用飞书或者企业微信做协作还可以接上 cc-connect 这类通知插件把 AI 的长任务运行结果推送到群组里。这在跑批量代码迁移或长时重构时非常方便任务在后台跑结束推一条消息不占终端。对于嵌入式场景比如 STM32 这类项目的助手配置也完全可以复用文中的链路只要把代码上下文和编译工具链挂到提示词里就能用。我个人这一圈实践下来最大的感受是Claude Code 和 Codex 在局域网离线环境下并非“能用不能用的区别”而是“配置得好不好”的区别。只要模型服务有足够的能力网关层的翻译和模型映射做得干净体验和直连公共 API 相比并不会差太多反而因为数据不出内网用起来更踏实。最后补一个小技巧给团队下发配置时把环境变量、config 文件、首次验证命令整合成一段脚本成员拷过去跑一次就能进入正常工作流比一份几十页的文档高效得多。
局域网离线跑通VibeCoding：Claude Code与Codex内网部署实践
正想聊聊 VibeCoding 这波趋势身边越来越多同事开始在终端里用 Claude Code、Codex 这类命令行的 AI 开发工具。工具确实好用但一提“局域网离线”四个字很多人第一反应就是“那还能用吗”。答案是能而且值得认真配置好。我这段时间在完全没外网出口的企业内网里把 Claude Code 和 Codex 都跑起来了代码全程不出内网请求全部落在局域网模型服务上。这篇就是我的完整落地记录从离线安装讲到报错排查适合内网开发者、有数据保密要求的项目组以及想把 VibeCoding 带到隔离网络里的工程师。1. 先搞明白 VibeCoding 是什么以及为什么非要在局域网里跑1.1 VibeCoding 的底层逻辑从“写代码”到“聊代码”VibeCoding 这个说法核心不是某个具体工具而是一种全新的编码姿势你用自然语言描述需求、报错、重构意图AI 在你授权范围内直接改代码、执行命令、跑测试然后你把结果 review 一遍合入版本库。Claude Code 和 Codex 就是这种模式的代表性 CLI 工具它们跑在终端里比 IDE 插件更主动能自主完成“读代码—定位问题—改文件—运行验证”的闭环。我自己的感受是它把很大一部分“搬砖”工作外包给了模型重构一个模块、补齐单元测试、排查一个晦涩的报错你只需要把上下文和约束说清楚剩下的交给模型迭代。传统补全工具是“你说一句它补一行”VibeCoding 是“你说目标它交出差量”。这类工具的共同点是需要一个高质量的模型服务。默认配置下Claude Code 会连 Anthropic 的云端接口Codex 会连 OpenAI 的云端接口。在办公网络环境里这套默认链路通常走不通而且就算走得通公司的代码片段被发送到外部服务这件事本身就有合规风险。于是“局域网离线”就不是一个可选项而是硬约束。1.2 离线和内网环境里到底缺什么、要补什么先盘点一下真实痛点。第一很多企业的研发网段根本没有外网出口npm、GitHub、云 API 全都不可达连装个包都得想办法第二代码资产是核心机密研发过程中的临时文件、会话记录、diff 内容都不允许离开内网第三团队需要一个统一的模型入口不能每个人各自连外面的服务既不好管控也没法记账审计。这就有点像在家里点外卖和自家开灶的区别。外卖方便但你的口味偏好、地址、甚至菜品照片都经过了外部平台自家开灶只要备好食材模型权重、锅铲推理服务和菜谱提示词工程就能在自家厨房里做出一桌菜。局域网离线方案的本质就是把“厨房”搬进内网。要补的东西有四个模型推理服务本身、一个兼容 Claude/OpenAI 接口的请求转发层、离线可用的安装源以及一套令牌和日志管理机制。下面我把每一步怎么落地都拆开来讲清楚。2. 离线环境先把工具装好Node.js、Claude Code、Codex2.1 解决 Node.js 和 npm 的离线安装与内网镜像Claude Code 和 Codex 都是基于 Node.js 的 CLI 工具所以第一步是准备一个干净的 Node.js 运行时。这里不建议用系统包管理器装因为离线环境下 apt 或 yum 的源未必可用我推荐直接下载官方 tar.xz 源码包进内网后解压即用。先在有网络的机器上下载 Node.js 20 LTS 的 linux-x64 tar.xz比如 node-v20.12.2-linux-x64.tar.xz拷进内网后执行sudo mkdir -p /opt/node sudo tar -xJf node-v20.12.2-linux-x64.tar.xz -C /opt/node --strip-components1然后把路径写进 /etc/profile.d/node.sh让所有用户都能直接用export PATH/opt/node/bin:$PATH验证一下node -v npm -v正常情况下会输出 v20.12.2 和对应的 npm 版本。如果内网有自建的 npm 镜像比如 Verdaccio、Nexus记得把 registry 指过去后面装全局包会顺畅很多npm config set registry http://你的镜像地址/repository/npm-public/如果没有内网镜像也别慌可以在外网机器上用npm pack把需要安装的包打成 tgz再拷进内网npm install -g。这个方法对任何 npm 包都通用唯一的坑是依赖树大的包要记得把依赖也一并打全。我通常的做法是在外面干净的目录里先完整装一次再用npm shrinkwrap锁定依赖之后打包带走。2.2 安装 Claude Code 和 Codex并确认版本可用Node.js 就绪后安装就简单了。Claude Code 的 npm 包名是anthropic-ai/claude-codeCodex 的包名是openai/codex。如果有内网镜像直接全局安装npm install -g anthropic-ai/claude-code npm install -g openai/codex装完验证版本claude --version codex --version这里要提醒三个离线安装常见的坑。第一个是 Node 版本太低两个工具都对 Node 版本有最低要求至少 18建议直接上 20。第二个是权限问题如果在全局目录没有写权限会报 EACCES要么用 sudo 装要么把 npm 的全局 prefix 指到用户目录。第三个是“装完了但命令找不到”Linux 下多半是 PATH 没包含全局 bin 目录检查一下/opt/node/bin或者~/.npm-global/bin是否在 PATH 里。如果内网连 npm 镜像都没有就走离线包路线。我的操作流程是在外网机器上npm pack anthropic-ai/claude-code得到 tgz 文件如果工具依赖原生二进制有些新版会在 postinstall 阶段下载二进制需要格外小心因为离线时 postinstall 会失败。这时候优先找已经编译好的 release 包或者在有网络的同架构机器上装好之后把整个 node 全局目录打包拷进去。实测下来同发行版同架构之间拷贝/opt/node下的 lib/node_modules 基本能跑但偶尔会遇到 glibc 版本不一致的问题最保险的还是目标机器上重新安装一遍。3. 把模型请求从云端切到局域网核心配置拆解3.1 Claude Code 的请求地址与令牌配置绕不开环境变量Claude Code 默认会把请求发到 Anthropic 官方 API但它的设计比较周到提供了两个关键环境变量来覆盖请求地址和身份验证信息ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN。只要设置了这两个变量所有请求都会走你指定的端点令牌也由你说了算。我推荐的配置方式不是写在 shell 配置文件里而是单独写一个环境文件比如/etc/cc-env.sh内容是export ANTHROPIC_BASE_URLhttp://你的局域网模型服务IP:8000/anthropic export ANTHROPIC_AUTH_TOKEN你的内网令牌 export ANTHROPIC_MODELqwen2.5-coder:32b export ANTHROPIC_SYSTEM_PROMPT你自己定制的系统提示词 export ANTHROPIC_LOG/data/cc-logs/claude.log然后在启动 Claude Code 之前source /etc/cc-env.sh再执行claude。之所以不写死在~/.bashrc里是因为同一台机器有时候也要跑公共云场景环境隔离更干净。除了环境变量Claude Code 也支持在~/.claude/settings.json里配置模型选项。比如我想让每次会话默认使用指定模型就在这里写{ model: qwen2.5-coder:32b, env: { ANTHROPIC_AUTH_TOKEN: 你的内网令牌 } }注意一点如果环境变量和配置文件里的值冲突环境变量的优先级更高。我会把不敏感的设置放在 settings.json 里方便团队统一敏感令牌则通过环境变量注入避免放进版本库。3.2 Codex 的供应商与模型配置Codex 的思路类似但配置结构更偏向“多供应商”模式。它支持 OpenAI 兼容协议而OPENAI_BASE_URL和OPENAI_API_KEY就是最基础的切流开关export OPENAI_BASE_URLhttp://你的局域网模型服务IP:8000/v1 export OPENAI_API_KEY你的内网令牌 export OPENAI_MODELdeepseek-chat需要注意 Codex 有两种接口形态。一种走/v1/chat/completions兼容大多数 OpenAI 代理程序另一种走较新的/v1/responses接口部分局域网服务端不一定实现。如果请求时遇到“endpoint 不支持”一类的问题优先检查是不是OPENAI_BASE_URL指到的服务端实现了对应的端点。多数情况下我会把服务端实现成同时暴露/v1/chat/completions和/v1/responses两个路径保证两个工具都能用。Codex 还支持在配置文件~/.codex/config.toml里声明model_providers通过自定义供应商来绑定多个模型地址[model_providers.internal] name internal base_url http://你的局域网模型服务IP:8000/v1 api_key_env_var OPENAI_API_KEY wire_api chat然后在[model]段里指定供应商对应的模型model internal/deepseek-chat这种写法的好处是团队可以维护一份标准 config每个人只改自己的 api_key模型切换通过版本库更新配置即可。3.3 一个能跑的局域网模型服务示例Ollama Qwen 系列前面讲的是客户端怎么切下面说说局域网里的模型服务端。最常见的快速方案是 Ollama它在离线环境下的部署成本极低单二进制、自带模型管理、默认支持 OpenAI 兼容接口。在局域网服务器上装好 Ollama启动前设置监听地址让它不要只绑定回环地址export OLLAMA_HOST0.0.0.0:11434 ollama serve然后在同网段的机器上验证服务是否可达curl http://局域网服务器IP:11434/api/tags能返回模型列表 JSON说明服务通了。接下来拉取代码模型。Ollama 官方的代码模型里我常用qwen2.5-coder系列有 7B、14B、32B 等多种规格。完全离线的网络可以通过在有外网的机器上ollama pull qwen2.5-coder:14b然后导出模型文件拷进内网后ollama create导入。但 Claude Code 默认发的是 Anthropic 风格请求Ollama 原生只提供 OpenAI 兼容接口中间还差一个“翻译”环节。我的做法是在内网服务器上部署一个请求流转网关比如 claude-code-router把 Anthropic 的/v1/messages请求翻译成 OpenAI/本地模型能理解的/v1/chat/completions。配置大概长这样{ provider: ollama, ollama: { base_url: http://127.0.0.1:11434, model: qwen2.5-coder:14b } }网关启动后监听 8000 端口对外暴露/anthropic路径Claude Code 的ANTHROPIC_BASE_URL指向它即可。Codex 更省事直接指到 Ollama 或者网关的/v1路径就能跑。如果内网允许访问特定的模型供应商 API比如通过合规审批的 DeepSeek 开放接口也可以直接把ANTHROPIC_BASE_URL指到供应商的 Anthropic 兼容端点。需要注意供应商提供的模型名必须和客户端填写的一致否则后面会出现“model is not supported”的报错这一点往下看。4. 高频报错与排查实录4.1 “auth token is unavailable” 这类认证问题怎么破在离线内网环境里Codex 很容易在启动时直接报出codex auth token is unavailable。这通常意味着 CLI 找不到可用的身份令牌。默认情况下Codex 会尝试交互式登录登录流程需要浏览器而内网机器既没有外网、也没有配置好的浏览器环境自然拿不到令牌。我的解决思路是绕开交互式登录直接用环境变量注入令牌。启动前明确设置OPENAI_API_KEY并确认~/.codex/auth.json不存在或至少不是过期的空文件。因为 Codex 的优先级逻辑里本地 auth 文件往往优先于环境变量一旦 auth.json 存在且无效会直接遮挡环境变量配置。实际操作时我习惯这么处理unset OPENAI_API_KEY # 先清理可能冲突的历史变量 export OPENAI_API_KEY你的内网令牌 codex --version如果还是不行就删除本机残留的~/.codex/auth.json再试。团队里我建议统一把令牌放在环境配置文件里通过部署脚本下发避免每个人手动管理。另一个容易被忽略的问题是令牌里如果带有特殊字符记得用单引号括起来否则 shell 会做变量展开导致最终请求头里的令牌和预期不一致。4.2 “model is not supported” 与“模型名对不上”的坑我在配置 Codex 接入局域网模型时遇到过一条很典型的报错the gpt-5.6-sol model is not supported when using codex with ...这行报错看起来像是服务端拒绝模型但真正原因往往是客户端用了默认的模型名而默认模型名只在官方的模型列表里存在。你服务端跑的是 DeepSeek 或 Qwen客户端填的却是 GPT 系列那自然不匹配。排查分三步。第一步用 curl 直接请求模型服务确认服务端支持的模型名列表。第二步在配置里把model改成列表里的准确名称。第三步检查有没有写透传模型名的格式比如 Codex 的vendor/model格式或者网关里的模型映射表。Claude Code 这边的相似问题是claude启动时默认找claude-*模型如果没有在 settings.json 或环境变量里覆盖ANTHROPIC_MODEL就会请求一个局域网服务根本不认识的模型名。这个问题在我接 Ollama 时反复出现最后统一在网关层做了模型名映射无论客户端传什么名字网关都把它替换成后端实际存在的模型。这样做的好处是团队成员的客户端配置可以完全统一服务端升级模型时只需改网关映射。4.3 本地转发服务连接异常的问题很多人在配置局域网环境时遇到过类似cc switch local proxy failed while handling codex endpoint这样的报错。我先说明一下这行错误信息是提示“本地转发服务在处理 Codex 请求时连接失败”而不是说你不能这么用。它的本质是客户端把请求交给了本机或局域网内的某个转发进程但那个进程没有正常响应。我排查这类问题固定按三步走。第一确认转发进程真的在监听端口。用ss -lntp | grep 8000看端口是否 LISTEN很多时候是服务没启动、或者启动后崩了。第二用 curl 测端点是否可通比如curl http://127.0.0.1:8000/v1/models如果 curl 都超时说明问题出在服务本身而不是客户端配置。第三检查证书策略。如果转发服务用了自签发证书而 CLI 默认强制校验 TLS就会在握手阶段失败表现为“连接失败”或“证书错误”。我自己的处理是给转发服务配置内部受信任的证书或者让客户端明确跳过 TLS 校验。还有一个内网特有的坑是监听地址写错。很多人把服务绑定在127.0.0.1然后客户端配置里写的是局域网 IP流量压根到不了服务。记住只在本机用就写 127.0.0.1要让同网段其他机器访问就是0.0.0.0或具体内网 IP。4.4 一张速查表把高频报错一次说清我把这段时间遇到的典型问题整理成了速查表方便大家对照处理。现象常见原因处理方式codex auth token is unavailable无浏览器登录态auth.json 残留设置 OPENAI_API_KEY清理 ~/.codex/auth.json确保环境变量优先级生效model is not supported模型名和实际服务端不匹配用 curl 查询模型列表统一改写客户端 model 配置在网关做模型名映射local proxy failed / 请求超时转发服务未启动监听地址错误TLS 证书不受信任检查端口监听用 curl 验证端点正确绑定 0.0.0.0配置内部证书或跳过校验npm install 时 getaddrinfo 失败离线环境 npm 未指向内网镜像配置内网 registry或使用 npm pack 离线安装启动后命令找不到PATH 未包含全局 bin 目录检查 /opt/node/bin 或 ~/.npm-global/bin 是否加入 PATH请求到达服务但返回 404服务端没有实现对应端点路径确认是否支持 /v1/chat/completions 或 /v1/responses检查网关路由配置这张表没有覆盖所有极端情况但内网环境里 80% 的问题都集中在认证、模型名、网络路径这三类。我一般建议在做任何复杂配置前先用 curl 把链路打通再上 CLI能少踩很多坑。5. 局域网离线下我用下来最顺手的几步走法5.1 我建议的落地顺序按这个来基本不折腾第一次搞这套东西最容易犯的错是先把 CLI 装好、把环境变量配好然后去连一个还没部署的模型服务最后面对一堆报错不知道是服务的问题还是客户端的问题。所以我的建议是严格按“服务端 → 验证链路 → 客户端 → 联调”的顺序来做。第一步先把局域网里的模型服务跑起来确认curl能拿到模型列表。第二步用一条最简单的非流式请求测试模型推理比如让模型返回一句“你好”确认输出正常。第三步把网关或转发层部署好再 curl 一遍网关的端点确认翻译后的请求能打到后端模型。第四步才安装配置 Claude Code 和 Codex。第五步用最小命令比如claude print hello验证确认通了再放开做真实任务。这个顺序能保证任何一步出问题你都能明确知道瓶颈在哪一层。我团队里入职的新同事按这个顺序操作最慢的也能在半小时内跑通。5.2 局域网不是绝对安全令牌和日志同样要管好很多人觉得“没有外网”就等于“绝对安全”这是错觉。内网也有横向渗透的风险而且多人共享一台模型服务时令牌如果不分权限任何一个开发者的令牌泄露都会影响整个团队。我的做法是模型服务用一个专用系统账号运行不给任何交互式 shell 权限每个团队成员分配单独的令牌服务端做最小权限映射不允许跨令牌访问其他目录。日志管理同样不能忽略。Claude Code 和 Codex 都会在本地保留会话记录里面可能包含代码片段。我在企业里会强制设置日志路径到一个统一目录并开启定期清理任务。同时提醒团队成员不要在 AI 会话里粘贴密钥、密码等敏感信息这条我会写进团队的约定文档里。最后内网服务尽量绑定在专门的研发网段不要直接暴露在办公网或访客网段必要时用 iptables 做来源 IP 限制。5.3 从命令行到桌面版、编辑器的扩展CLI 跑通之后还可以往周边扩展。VSCode 里可以通过终端面板内嵌运行 Claude Code 或 Codex体验上接近 IDE 插件但能力仍然是 CLI 的完整形态。桌面版Claude Code Desktop在有外网的环境下用得很火但在内网环境我更推荐直接用claude命令配合 tmux 使用少一层壳就少一份配置复杂度。另外如果你们团队平时用飞书或者企业微信做协作还可以接上 cc-connect 这类通知插件把 AI 的长任务运行结果推送到群组里。这在跑批量代码迁移或长时重构时非常方便任务在后台跑结束推一条消息不占终端。对于嵌入式场景比如 STM32 这类项目的助手配置也完全可以复用文中的链路只要把代码上下文和编译工具链挂到提示词里就能用。我个人这一圈实践下来最大的感受是Claude Code 和 Codex 在局域网离线环境下并非“能用不能用的区别”而是“配置得好不好”的区别。只要模型服务有足够的能力网关层的翻译和模型映射做得干净体验和直连公共 API 相比并不会差太多反而因为数据不出内网用起来更踏实。最后补一个小技巧给团队下发配置时把环境变量、config 文件、首次验证命令整合成一段脚本成员拷过去跑一次就能进入正常工作流比一份几十页的文档高效得多。
