Codex 在 VS Code 中的完整使用指南（安装、登录、工作流与最佳实践）

原创 2026-03-02 10:47:41 7.9w 阅读 AI写同款

收录于

嵌入式孙老师

码龄7年墨衍会员 · AI 创作全网分发

5686粉丝898篇原创

关注

VS Code + Codex 在 WSL 中使用的正确姿势 Codex 登录只能在本地完成。文件仍可通过 UNC 路径访问 WSL → 本地 Codex 就能照常工作。避免在 WSL 内重复安装/登录 Codex 扩展。阅读详情

📺 B站：博主个人介绍

📘 博主书籍-京东购买链接*：Yocto项目实战教程

📘 加博主微信，进技术交流群： jerrydev

Codex 在 VS Code 中的完整使用指南（安装、登录、工作流与最佳实践）

适用人群：希望在 VS Code 里“直接让 AI 帮你写、改、跑、验收代码”的开发者。本文面向实战：从安装登录，到可控工作流、配置与安全策略，给你一套能长期使用的打法。

0. 10 分钟上手路线（先跑通再优化）

安装 VS Code 扩展：Codex – OpenAI’s coding agent（发布者：OpenAI）。
打开 Codex 侧边栏 → Sign in with your ChatGPT account（浏览器授权）或选择 API Key。
打开你的工程目录（Workspace）→ 标记为 Trusted（可信工作区）。
在 Codex 输入框下方切到 Agent（默认）模式。
选中一段代码（或打开 2~3 个相关文件）→ 让它“先给计划，再提交补丁”。

跑通这 5 步，你就已经进入 Codex 的正确使用方式：工程上下文 + 可审查改动 + 可闭环验证。

在这里插入图片描述

1. Codex 到底是什么：它不是“聊天插件”，而是编码代理

很多人把 Codex 当作“IDE 里的 ChatGPT”。

更准确的定位：Codex 是一个编码代理（coding agent），目标是帮助你“写、评审、交付代码”。它的强项不是聊得多，而是：

读懂你的工程上下文：利用你打开的文件、选中代码、工作区结构。
以补丁（diff）方式产出改动：让你能审查、回滚、拆分提交。
能跑命令形成闭环：构建、测试、格式化、lint、日志分析，然后继续修。
可委托大任务到云端：把较大、较慢的任务交给 Codex Cloud 处理，再回到本地接棒验收。

一句话：把它当作“会提交补丁的同事”，你负责目标与验收，它负责执行与迭代。

2. 选哪个扩展：优先用 OpenAI 官方的 Codex

VS Code 市场里“GPT/ChatGPT”相关扩展很多。

如果你追求：

更稳定的登录、更新与能力一致性
更贴近官方工作流（Agent/Chat、审批与沙箱）

建议直接用 OpenAI 官方扩展：

Codex – OpenAI’s coding agent（发布者：OpenAI）

第三方扩展也能用，但通常需要额外配置多家 API Key、权限策略，且体验差异较大。

3. 安装与登录：两种方式，优先用 ChatGPT 账号

3.1 安装

VS Code → Extensions（扩展）
搜索 Codex – OpenAI’s coding agent
安装后，左侧活动栏会出现 Codex 图标（有时在折叠区）

3.2 登录方式 A：ChatGPT 账号（推荐）

打开 Codex 面板
点击 Sign in with your ChatGPT account
浏览器打开授权页 → 登录 → Allow/Approve
回到 VS Code，Codex 显示已登录

多数 ChatGPT 订阅（如 Plus/Pro/Business/Edu/Enterprise）包含 Codex 能力。

3.3 登录方式 B：API Key（可选）

如果你需要：

团队统一计费/配额
企业网络限制无法走账号授权

可选择 API Key 登录（在 Codex 面板/设置中选择 API Key 方式）。

3.4 常见登录卡点（快速排查）

点登录没反应：VS Code 命令面板 → Developer: Reload Window。
浏览器授权成功但 VS Code 还没登录：退出重新登录；检查是否有拦截弹窗/第三方 cookie。
企业网络：尝试切换网络/代理规则；确保登录域名不被拦截。

4. 三个最重要的概念：模式、沙箱、审批

Codex 好用的关键，是把“能力”变成“可控”。你必须理解这三件事：

4.1 模式（Mode）：Chat vs Agent vs Agent (Full Access)

Chat：只讨论与规划，适合“先想清楚再动手”。
Agent（默认）：在工作目录内读/改/跑命令；访问工作区外或网络通常需要你确认。
Agent (Full Access)：权限更大，适合确实需要网络/更广范围操作的场景；建议短期开启，用完即关。

实战建议：日常开发 Agent 足够。除非你明确需要网络访问，否则不要常开 Full Access。

4.2 沙箱（Sandbox）：它“技术上能做什么”

沙箱决定了 Codex 的可达范围，比如：

可写哪些目录
能不能访问网络
能不能运行某些命令

4.3 审批策略（Approval policy）：它“什么时候必须问你”

审批策略决定它在执行动作前是否弹确认，例如：

运行命令
离开工作目录
访问网络

实战建议：选择“更窄的批准范围”更安全。不确定时，先 approve once（仅一次），再观察它的行为。

5. Codex 的“上下文”怎么喂：越精准越强

Codex 不是读心术，它靠上下文做判断。你提供得越清晰，它越稳定。

5.1 三种最有效的上下文来源

打开相关文件（2~5 个足够）：入口文件、关键接口、调用点。
选中关键代码段：函数、结构体、配置块。
明确范围与约束：
- “只改这些文件：@a.c @b.h”
- “不要动 third_party/ vendor/ toolchain”

5.2 用 `@文件` 做精确引用

当工程大、路径深时，强烈建议用 @ 明确文件：

请解释 @drivers/foo.c 的 probe 流程，并指出资源释放路径。
请基于 @meta-layer/recipes-app/app.bb 修复 do_install 报错，给出最小补丁。

5.3 让它先“复述任务理解”

你可以强制它先对齐目标：

在开始改动前，请用 5 行复述：你理解的目标、约束、验收标准。

这一步能显著减少“改偏了”。

6. 可复制的五类工作流（从简单到复杂）

6.1 工作流 1：读懂陌生仓库（建立心智地图）

目标：快速搞清入口、模块职责、关键数据结构、生命周期。

提示模板：

以 @main.c 为入口，输出模块级流程（编号列表），并标注每一步对应的文件/函数。
列出这个模块最容易失败的 5 条路径（错误处理/资源释放/并发）。

6.2 工作流 2：修 Bug（最小改动 + 可验证）

目标：只修问题，不顺手大改；补测试或检查点防回归。

提示模板：

这是复现步骤与日志：...。请先定位根因，再提交“最小补丁”。不要重构。补一个回归测试或检查点。
只允许改：@a.c @b.h。其它文件一律不改。

6.3 工作流 3：重构（先计划后补丁，分步提交）

目标：结构更清晰，但风险可控。

提示模板：

先给 6 步重构计划（含风险点与回滚策略），我确认后再生成 patch。验收标准：行为不变/测试通过。

6.4 工作流 4：新增功能（用验收标准驱动实现）

提示模板：

新增功能：X。验收标准：1)... 2)... 3)...。请拆成 3 个提交：接口/实现/测试与文档。

6.5 工作流 5：构建与日志闭环（非常适合 Yocto/内核/OTA）

提示模板：

这是 bitbake 报错/编译日志/链接错误：...。请定位根因，给出可执行修复步骤 + 最小补丁，并说明为什么这样改。
这是 dmesg/journalctl：...。请指出最可能的触发链路，并建议我先验证的 3 个观察点（命令/路径）。

7. Prompt Playbook：10 条高命中提示词（复制即用）

只解释不修改：请解释 @file 的职责、入口、关键数据结构、失败路径。
只改一个文件：只允许改 @foo.c，目标是修复这个崩溃点，给最小补丁。
先计划：先输出修改计划 + 风险点 + 验收项，通过后再生成 patch。
不要改变行为：只做重构（保持输出一致），并补充注释与边界检查。
补测试：为这个 bug 增加最小回归测试，确保未来能被捕获。
保持项目风格：不引入新依赖、不改命名风格、不做无关格式化。
解释构建失败：解析这段 gcc/ld/bitbake 输出，定位根因并给修复提交。
安全审查：检查是否有密钥泄漏、命令注入、不安全默认值，并给出修复建议。
性能约束：只优化热点路径，给出基准方法与预期收益，避免过度设计。
可回滚提交：拆成两次提交：功能 commit + 清理/文档 commit，便于回滚。

8. 最佳实践：让 Codex “稳、快、可控”的 8 条铁律

小步迭代：一次只解决一个目标（修 bug / 加日志 / 补测试）。
先计划后补丁：复杂任务必须先出计划与风险点。
写清验收标准：例如“编译通过、单测通过、行为不变”。
限制改动范围：明确“只改哪些文件/目录”。
所有改动必须 review diff：尤其是错误处理与资源释放。
先本地验证再合入：跑构建、跑测试、跑 lint。
Git checkpoint：任务前后各一次提交，必要时用分支。
权限最小化：默认 Agent；只在必要时开 Full Access。

9. 配置：把 Codex 调成你的默认开发搭档

Codex 支持用户级与项目级配置，并且 CLI 与 IDE 扩展共享同一套配置层。

9.1 配置文件位置

用户级：~/.codex/config.toml
项目级：<repo>/.codex/config.toml

为安全起见，Codex 只会在项目被标记为 Trusted 时加载项目级 .codex/config.toml。

9.2 从 VS Code 直接打开配置

通常在 Codex 面板右上角齿轮（⚙️）里，能找到类似：

Codex Settings → Open config.toml

9.3 一个建议的“保守型默认配置”（可直接粘贴）

# ~/.codex/config.toml
# 目标：日常开发稳定、安全、可控

# 默认模型（按你账户可用情况选择）
model = "gpt-5.2"

# 审批策略：更保守更安全（具体可选值以官方参考为准）
approval_policy = "on-request"

# 沙箱模式：只在工作区内写入（减少误操作范围）
sandbox_mode = "workspace-write"