【免费下载链接】jetbrains-cc-guiJetbrains Claude Code and Codex GUI Plugin项目地址https://gitcode.com/gh_mirrors/id/jetbrains-cc-gui点击查看免费下载本篇技术指南以 Codex CLI 官方 FAQ 为主体脉络系统梳理其最常被问到的十大问题模型支持与推理强度、沙箱与审批的协作机制、codex exec非交互自动化、如何阻止 Codex 修改文件、MCP 服务器接入、登录排错、Windows 支持以及 Homebrew 升级踩坑。文章在完整继承 FAQ 与官方文档细节的基础上结合 jetbrains-cc-gui 仓库中 Codex 接入层的源码实现ai-bridge/services/codex/与ai-bridge/utils/permission-mapper.js为你解释每个答案背后的配置原理与底层机制读完即可直接落地配置和排障。一、2021 年的 Codex 模型与本项目使用的 Codex CLI 有何关系FAQ 首先澄清了一个常见混淆2021 年 OpenAI 发布的Codex是一个从自然语言提示生成代码的 AI 系统该模型已于2023 年 3 月弃用它与当前作为命令行工具的Codex CLI是两个完全不同的东西——Codex CLI 是一个运行在本地、面向终端和 IDE 的编码 Agent本仓库jetbrains-cc-gui正是把它作为 JetBrains IDE 内的一个智能助手通道来集成。从仓库源码可以看到这种工具化集成的定位ai-bridge/channels/codex-channel.js 中通过handleCodexCommand(command, args, stdinData)暴露了send、getMcpServerTools、listModels三个命令把 GUI 的请求翻译成 Codex SDK 调用而 ai-bridge/services/codex/message-service.js 顶部注释明确写道Message sending through Codex SDK (openai/codex-sdk)… Key Differences from Claude: Uses threadId instead of sessionId; Permission model: skipGitRepoCheck sandbox approvalPolicy。所以当文档讨论Codex时指的是这个可编程、可配置的 CLI/SDK 工具链而不是 2021 年的那个生成代码模型。二、支持的模型与推理强度从gpt-5.1-codex-max到/model与--model推荐模型与默认推理级别官方推荐使用GPT-5.1 Codex Maxgpt-5.1-codex-max这是当前最佳的编码模型。默认推理级别reasoning effort为medium对于复杂任务可以通过/model命令升级到high或xhigh后者在gpt-5.1-codex-max、gpt-5.2上可用。也可以使用较老的模型通过API 认证codex login --with-api-key并配合--model标志启动codex --model gpt-5.1 解释这个代码库 codex exec --model gpt-5.1-codex-max --json Review the change, look for use-after-free issues推理强度与相关配置项在 docs/codex/docs/config.md 中model_reasoning_effort支持五个取值取值说明minimal最小化推理追求速度low低强度推理medium默认值high高强度推理适合复杂任务xhigh仅在gpt-5.1-codex-max、gpt-5.2等模型上可用# ~/.codex/config.toml model gpt-5.1-codex-max model_reasoning_effort high model_reasoning_summary detailed # auto / concise / detailed / none仓库的 GUI 层直接透传这一能力在 ai-bridge/services/codex/message-service.js 中reasoningEffort参数默认medium被写入threadOptions.modelReasoningEffort。而 ai-bridge/services/codex/models-service.js 则通过解析~/.codex/config.toml的顶层model、model_provider、model_catalog_json键来发现模型列表保证 GUI 中展示的模型与codex命令自身的模型选择器一致——这就是为什么你在 IDE 中看到的模型下拉框与终端里一致。三、审批Approvals与沙箱模式Sandbox如何协同工作这是 FAQ 中最核心的概念问题值得展开细讲。两个正交的维度审批ApprovalsCodex 在执行需要提升权限的工具调用前征询你的机制——典型场景是离开沙箱或在无隔离条件下重跑一条失败命令。沙箱模式Sandbox提供基线隔离级别共三档Read Only只读、Workspace Write工作区可写、Danger Full Access完全访问。详见 docs/codex/docs/sandbox.md。默认行为保守起步Codex 启动时非常保守。在未显式信任工作目录之前CLI 默认read-only可以读文件、回答问题但每次编辑和命令执行都需要审批。当你通过引导提示或/approvals → Trust this directory标记目录为可信后默认预设升级为Agent允许在工作区内写入只有需要离开工作区或在沙箱外重跑命令时才会打断你。注意工作区包含工作目录以及/tmp等临时目录可用/status确认精确的可写根。常用组合速查表意图标志组合效果安全只读浏览--sandbox read-only --ask-for-approval on-request可读文件、回答问题编辑、跑命令、访问网络需审批只读非交互CI--sandbox read-only --ask-for-approval never只读永不升级权限可编辑仓库、风险操作询问--sandbox workspace-write --ask-for-approval on-request可读写工作区工作区外操作或网络访问需审批Auto预设可信仓库--full-auto等价于 workspace-write on-request沙箱内命令可写工作区需离开沙箱时才升级YOLO不推荐--dangerously-bypass-approvals-and-sandbox别名--yolo无沙箱、无提示注意workspace-write模式下网络默认禁用除非在配置中开启[sandbox_workspace_write].network_access true。完全免审批可以完全禁用审批提示--ask-for-approval never。该选项可与所有--sandbox模式组合使用你仍然掌控 Codex 的自主程度它会在给定约束下尽力而为。沙箱机制的底层实现分平台平台机制macOS 12Apple Seatbelt调用sandbox-exec用与所选--sandbox模式对应的 profile 在 OS 级别限制文件系统与网络Linux组合Landlock与seccompAPI 近似实现要求内核支持。容器化环境如 Docker若未暴露 Landlock/seccomp沙箱可能失效此时应在容器内自行提供隔离并以--sandbox danger-full-access运行Windows实验性基于 AppContainer 派生受限令牌仅授予明确请求的文件系统能力通过覆盖代理环境变量与插入桩可执行文件禁用出站网络。主要限制是无法阻止 Everyone SID 已有写权限目录下的写入如全局可写目录。详见 docs/codex/docs/windows_sandbox_security.md仓库源码中的沙箱与审批映射jetbrains-cc-gui 在接入层把统一的权限模式翻译成 Codex 的三元组sandbox approvalPolicy skipGitRepoCheck实现位于 ai-bridge/utils/permission-mapper.js 的CodexPermissionMapper.toProvider()sandbox只读模式→sandbox: read-onlyapprovalPolicy: on-requestdefault默认模式→sandbox: workspace-writeapprovalPolicy: on-requestauto原生自动审批模式→sandbox: workspace-writeapprovalPolicy: on-requestapprovalsReviewer: auto_review由 Codex 自身的审批审查器处理请求yolo完全访问模式→sandbox: danger-full-accessapprovalPolicy: never。同时 ai-bridge/services/codex/codex-utils.js 定义了合法取值集合export const VALID_SANDBOX_MODES new Set([read-only, workspace-write, danger-full-access]); export const VALID_APPROVAL_POLICIES new Set([never, on-request, on-failure]);一个值得注意的版本事实来自源码注释approval_policy untrusted已在 Codex CLIv0.149.0中移除其先询问再运行语义合并进on-request继续传该值会让新版本 CLI 以approval_policy untrusted is no longer supported报错退出对应 issue #1702。此外 Windows 上由于沙箱处于实验阶段default/acceptEdits/bypassPermissions等模式会被映射为danger-full-access以保证写入操作正常ai-bridge/utils/permission-mapper.js 的isWindows()判断。GUI 侧还会做环境净化buildCodexCliEnvironment会把CODEX_APPROVAL_POLICY、CODEX_SANDBOX_MODE、CODEX_SANDBOX、CODEX_SANDBOX_NETWORK_DISABLED、CODEX_CI从传给 SDK 的环境中剔除ai-bridge/services/codex/codex-utils.js防止宿主 IDE 的污染环境变量破坏审批策略而CODEX_SANDBOX_MODE/CODEX_APPROVAL_POLICY环境变量仍可作为显式覆盖resolveSandboxModeOverride/resolveApprovalPolicyOverride会校验取值合法性后生效。沙箱行为实验想验证命令在沙箱下的行为用 CLI 自带助手# macOS codex sandbox macos [--full-auto] [COMMAND]... # Linux codex sandbox linux [--full-auto] [COMMAND]... # 旧版别名 codex debug seatbelt [--full-auto] [COMMAND]... codex debug landlock [--full-auto] [COMMAND]...四、不用 TUI 也能自动化codex exec非交互模式FAQ 明确指出可以。codex exec以非交互模式运行 Codex支持流式日志、JSONL 输出和结构化 Schema且遵循你在 配置指南 中配置的同一套沙箱与审批设置。codex exec count the total number of lines of code in this project非交互模式下 Codex不会询问命令或编辑审批默认以read-only运行因此不能编辑文件或执行需要网络的命令。用codex exec --full-auto允许文件编辑用codex exec --sandbox danger-full-access允许编辑和联网命令。输出模式默认活动流式输出到 stderr仅把 Agent 的最终消息写到 stdout便于管道接入其他工具-o/--output-last-message可把输出写入文件。JSON 模式--json把事件以 JSON LinesJSONL流式输出到 stdout。事件类型包括thread.started、turn.started、turn.completed含 token 用量、turn.failed含错误详情、item.started/item.updated/item.completed、error条目类型包括agent_message、reasoning、command_execution、file_change、mcp_tool_call、web_search、todo_list。示例输出{type:thread.started,thread_id:0199a213-81c0-7800-8aa1-bbab2a035a53} {type:turn.started} {type:item.completed,item:{id:item_0,type:reasoning,text:**Searching for README files**}} {type:item.completed,item:{id:item_1,type:command_execution,command:bash -lc ls,aggregated_output:...,exit_code:0,status:completed}} {type:item.completed,item:{id:item_3,type:agent_message,text:Yep — there’s a README.md in the repository root.}} {type:turn.completed,usage:{input_tokens:24763,cached_input_tokens:24448,output_tokens:122}}仓库的 ai-bridge/services/codex/codex-event-handler.js 正是按这套事件模型实现的对agent_message、command_execution、file_change、mcp_tool_call等item.completed类型分派到各自的处理器把 Codex 流事件转换为 GUI 可以渲染的标准化消息。结构化输出--output-schema接受一个遵循 OpenAI 严格 Schema 规则的 JSON Schema 文件定义期望的 JSON 输出{ type: object, properties: { project_name: { type: string }, programming_languages: { type: array, items: { type: string } } }, required: [project_name, programming_languages], additionalProperties: false }codex exec Extract details of the project --output-schema ~/schema.json结合-o只打印最终 JSON也可给-o传文件路径把 JSON 保存到文件。Git 仓库要求与会话恢复Codex 要求处于 Git 仓库中以避免破坏性变更codex exec --skip-git-repo-check可跳过该检查。恢复非交互会话codex exec resume SESSION_ID或codex exec resume --last只保留对话上下文行为仍由你传入的标志控制。仓库的 ai-bridge/services/codex/message-service.js 印证了这一点GUI 层区分新线程与恢复线程——恢复线程threadId非空时跳过workingDirectory设置以便会话查找分别调用codex.resumeThread(threadId, threadOptions)或codex.startThread(threadOptions)。认证与环境变量codex exec默认使用与 CLI 和 VS Code 扩展相同的认证方式也可用CODEX_API_KEY环境变量覆盖注意CODEX_API_KEY仅在codex exec中受支持CODEX_API_KEYyour-api-key-here codex exec Fix merge conflict五、如何阻止 Codex 修改你的文件默认情况下 Codex 可以修改当前工作目录中的文件Auto 模式。两种阻止方式只读启动用 CLI 标志--sandbox read-only启动codex。会话中途调整用/approvals切换审批级别。对应到配置文件~/.codex/config.toml# 等价于 --sandbox read-only sandbox_mode read-only # 等价于 --sandbox workspace-write sandbox_mode workspace-writeworkspace-write下工作目录与$TMPDIRmacOS可写且 macOS以及未来的 Linux上任何可写根若以.git/或.codex/作为直接子目录这些目录本身会被设为只读——所以git commit默认会失败涉及写.git/需要 Codex 请求许可。追加可写根、排除临时目录、开启网络等均可通过[sandbox_workspace_write]表配置docs/codex/docs/config.md。六、如何连接 MCP 服务器在config.toml中通过[mcp_servers.server-name]表配置详见 docs/codex/docs/config.md#mcp_servers 的 Connecting to MCP servers 一节。STDIO 服务器本地命令启动[mcp_servers.server_name] command npx args [-y, mcp-server] env { API_KEY value } # 可选额外环境变量 env_vars [API_KEY2] # 可选追加白名单变量 cwd /Users/user/code/my-server # 可选命令运行目录Streamable HTTP 服务器URL 访问[mcp_servers.figma] url https://mcp.figma.com/mcp bearer_token_env_var ENV_VAR # 可选Bearer token 的环境变量名 http_headers { HEADER_NAME HEADER_VALUE } # 可选硬编码头 env_http_headers { HEADER_NAME ENV_VAR } # 可选来自环境变量的头通用选项startup_timeout_sec默认 10 秒启动超时、tool_timeout_sec默认 60 秒单工具超时、enabled false禁用但保留、enabled_tools仅暴露子集、disabled_tools隐藏指定工具与enabled_tools同时设置时先做白名单再做黑名单。CLI 管理命令codex mcp --help # 所有可用命令 codex mcp add docs -- docs-server --port 4000 codex mcp list / codex mcp list --json codex mcp get docs / codex mcp get docs --json codex mcp remove docs codex mcp login SERVER_NAME # 对支持 OAuth 的 HTTP 服务器登录 codex mcp logout SERVER_NAME仓库侧codex-channel.js的getMcpServerTools命令会把serverId与serverConfig透传给底层实现GUI 内可直接枚举 MCP 服务器工具codex exec的 JSON 事件流中也会出现mcp_tool_call类型的条目见上文事件模型。七、登录遇到问题三步排查法FAQ 给出的排查流程走一遍 认证文档 中的认证流程确认~/.codex/auth.json中存在正确的凭据。如果在无头headless或远程机器上确认端口转发已按 Authentication → Connecting on a Headless Machine 配置好。认证方式细节API Key按量计费printenv OPENAI_API_KEY | codex login --with-api-key # 或从文件读取 codex login --with-api-key my_key.txt旧的--api-key标志现已报错并引导使用--with-api-key以避免密钥出现在 shell 历史或进程列表。该 Key 至少需要 Responses API 的写入权限。从 API Key 迁移到 ChatGPT 登录先更新 CLI 至codex --version≥ 0.20.0删除~/.codex/auth.jsonWindowsC:\Users\USERNAME\.codex\auth.json再运行codex login。无头机器方案登录流程会在localhost:1455起一个服务。两个常见解法本地完成认证后拷贝凭据本地走完codex login后把$CODEX_HOME/auth.json拷到目标机器。Docker 用docker cp远程机用scpssh userremote mkdir -p ~/.codex scp ~/.codex/auth.json userremote:~/.codex/auth.json端口转发远程执行前在本地做 SSH 隧道ssh -L 1455:localhost:1455 userremote-host然后在远程会话中运行codex选择 Sign in with ChatGPT本地浏览器打开http://localhost:1455/...即可完成认证。八、Windows 支持情况直接在 Windows 上运行 Codex可能可用但官方不保证支持。官方建议使用Windows Subsystem for LinuxWSL2。FAQ 原文指向的 WSL 安装说明见官方文档。仓库源码同样反映了这一前提CodexPermissionMapper中isWindows()检测到 Windows 平台时会把需要写入的模式一律映射为danger-full-access注释明确写道 Windows sandbox support is experimental, so we use danger-full-access mode on Windows to ensure write operations work correctlyai-bridge/utils/permission-mapper.js。此外配置文档中还有features.enable_experimental_windows_sandbox默认 false用于启用 Windows 受限令牌沙箱以及codex-utils.js中VALID_SANDBOX_MODES对三种模式的校验——这些都说明Windows 上沙箱仍属实验能力生产使用请走 WSL2。九、安装后的第一步应该做什么按 安装与构建 完成快速设置然后进入 Getting started 了解交互式用法、提示词示例与 AGENTS.md 指引。系统要求要求细节操作系统macOS 12、Ubuntu 20.04/Debian 10、或 Windows 11经 WSL2Git可选推荐2.23用于内置 PR 辅助内存最低 4 GB推荐 8 GB常用 CLI 用法命令用途示例codex交互式 TUIcodexcodex ...带初始提示词进入 TUIcodex fix lint errorscodex exec ...非交互自动化模式codex exec explain utils.ts常用标志--model/-m、--ask-for-approval/-a工作目录相关--cd/-C指定工作根、--add-dir会话中追加可写根如codex --cd apps/frontend --add-dir ../backend会话恢复codex resume选择器、codex resume --last、codex resume SESSION_ID、codex resume --all显示原始 CWD。AGENTS.md 记忆机制Codex 按以下顺序发现并自顶向下合并AGENTS.md~/.codex/AGENTS.md—— 个人全局指引从仓库根目录到当前工作目录的每一级目录优先使用AGENTS.override.md否则回退AGENTS.md。仓库 GUI 层同样实现了一致的行为在 ai-bridge/services/codex/message-service.js 中新线程启动时会调用collectAgentsInstructions(cwd)收集指令并以前缀块agents-instructions.../agents-instructions注入首条消息。相关实现位于 ai-bridge/services/codex/codex-agents-loader.js。交互技巧速览触发文件模糊搜索Esc–Esc编辑上一条消息回溯并 fork 对话CtrlV/CmdV或-i/--image附加图片如codex -i screenshot.png Explain this errorcodex completion bash|zsh|fish生成 shell 补全。启动前先配置好环境激活虚拟环境、启动守护进程、导出环境变量避免 Codex 浪费 token 探测环境。十、brew upgrade codex不升级从 formula 迁移到 cask如果你运行的是Codex v0.46.0 或更早版本brew upgrade codex不会把你升级到最新版因为官方已从 Homebrewformula 迁移到 cask。解决方法是先卸载旧的 formula再安装新的 caskbrew uninstall --formula codex brew install --cask codex重装后brew upgrade --cask codex就能保持后续版本持续更新。附录快速参考与仓库延伸阅读配置优先级从高到低命令行专属标志如--model o3Profile 内的配置--profile指定config.toml条目如model o3Codex CLI 内置默认值默认模型gpt-5.1-codex-max。通用-c/--config keyvalue可覆盖任意层且值按 TOML 语法解析如--config shell_environment_policy.include_only[PATH, HOME, USER]配置主文件位于$CODEX_HOME/config.tomlCODEX_HOME默认~/.codex。核心配置项速查键类型/取值说明modelstring使用的模型如gpt-5.1-codex-maxmodel_providerstring来自model_providers的 Provider id默认openaiapproval_policyuntrusted已移除|on-failure|on-request|never何时提示审批sandbox_moderead-only|workspace-write|danger-full-accessOS 沙箱策略sandbox_workspace_write.writable_rootsarrayworkspace-write 下的额外可写根sandbox_workspace_write.network_accessbooleanworkspace-write 允许网络默认 falsemodel_reasoning_effortminimal|low|medium|high|xhighResponses API 推理强度model_reasoning_summaryauto|concise|detailed|none推理摘要mcp_servers.id.*见上文MCP 服务器配置features.flagboolean特性开关web_search_request、view_image_tool等history.persistencesave-all|none历史持久化默认save-allfile_openervscode|vscode-insiders|windsurf|cursor|none输出引用的可点击 URI 方案默认vscode完整的参数参考表见 docs/codex/docs/config.md 末尾的 Config reference 一节。本仓库的 Codex 接入层可对照阅读ai-bridge/services/codex/message-service.jsCodex SDK 消息发送协调器演示 threadId、sandbox、approvalPolicy、skipGitRepoCheck、reasoningEffort 的组装与线程恢复逻辑ai-bridge/utils/permission-mapper.js统一权限模式与 Codex 原生权限三元组的双向映射ai-bridge/services/codex/codex-utils.js合法沙箱/审批取值校验、环境净化与审批审查器配置ai-bridge/services/codex/models-service.js解析~/.codex/config.toml与模型目录 JSON 以发现可用模型ai-bridge/services/codex/codex-event-handler.jsagent_message/command_execution/file_change/mcp_tool_call等流事件的分派与标准化ai-bridge/channels/codex-channel.jsGUI 命令入口send/getMcpServerTools/listModels。通过 FAQ 与上述源码对照阅读你可以把模型选型、权限边界、自动化运行、登录排障这条主线完整落地到自己的 IDE 与 CI 工作流中。赞分享【免费下载链接】jetbrains-cc-guiJetbrains Claude Code and Codex GUI Plugin项目地址https://gitcode.com/gh_mirrors/id/jetbrains-cc-gui点击查看免费下载相关推荐JetBrains CC GUI 原生自动审批模式Native Auto-Approval Mode深度解析Claude auto 与 Codex auto_review 的接入与隔离设计JetBrains CC GUI 原生自动审批模式Native Auto Approval Mode深度解析Claude auto 与 Codex autJetBrains CC GUI Codex 输出不显示问题排查与调试指南JetBrains CC GUI Codex 输出不显示问题排查与调试指南 导读 本文面向 JetBrains Claude Code and Codex GUJetBrains 插件中的 Codex 沙箱与审批策略从 read-only 到 full-auto 的完整权限模型解析JetBrains 插件中的 Codex 沙箱与审批策略从 read only 到 full auto 的完整权限模型解析 导读 Codex 的能做什么上一篇Escrcpy 中的 Scrcpy 快捷键完全指南MOD 修饰键、窗口控制与设备按键操作速查下一篇一键把抖音视频批量下载保存到本地douyin-downloader 一次搞定创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考