Codex 中文手冊

繁體中文

简体中文

繁體中文

简体中文

外觀

交流群即將上線

常見問題 FAQ ​

安裝與登入 ​

codex 裝完了但指令找不到 ​

安裝指令碼把二進位制放在一個目錄裡，但那個目錄不在你的 PATH 上。 重開一個終端先試試；還不行就看安裝指令碼的輸出，它會告訴你裝到哪了， 把那個目錄加進 PATH。用 npm 或 Homebrew 裝一般不會有這個問題。

該用 ChatGPT 賬號還是 API 金鑰登入 ​

兩條路的差別不只是計費。用 ChatGPT 賬號，你的使用受 ChatGPT 工作區權限、 RBAC 和 ChatGPT Enterprise 的資料保留/駐留設定約束；用 API 金鑰， 適用的是你所屬 API 組織的設定。

另外 Codex 雲端必須用 ChatGPT 登入，API 金鑰用不了， 而且用 API 金鑰時部分功能可能不可用。

公司環境裡基本上是被決定好的：管控掛在 ChatGPT 工作區上，就得用賬號登入。 詳見 快速上手 02。

一臺機器能同時裝 CLI、IDE 擴充功能和桌面應用嗎 ​

能，登入狀態各自獨立。而且 CLI 和 IDE 擴充功能共用同一套配置層 （~/.codex/config.toml），MCP 伺服器配一次兩邊都能用。

權限與沙盒 ​

--sandbox 和 --ask-for-approval 有什麼區別 ​

一個管能力上限，一個管打斷頻率：

  • --sandbox：它執行指令時技術上能做到什麼（能寫哪、能不能聯網）
  • --ask-for-approval：哪些動作必須先停下來問你

-a never 不等於放開權限——沙盒該攔還是攔。真正放開是 --sandbox danger-full-access。 完整對照見 快速上手 04。

預設能聯網嗎 ​

不能。預設情況下智慧體在關閉網路存取的狀態下執行。 workspace-write 也預設禁網，要開得顯式配：

toml
[sandbox_workspace_write]
network_access = true

「工作區」到底包括哪些目錄 ​

當前目錄，加上 /tmp 之類的臨時目錄。拿不準就在工作階段裡 /status 看一眼。

它會不會改我的 .git ​

不會。workspace-write 下這幾個路徑受遞迴只讀保護：

  • <可写根目录>/.git（是 gitdir: 指標檔案的話，解析出的真實目錄也保護）
  • <可写根目录>/.agents
  • <可写根目录>/.codex

所以 git diff / git checkout 這條退路始終有效。

核准提示太多，但我又不想直接 never ​

兩個中間選項：

toml
approval_policy = "on-request"
approvals_reviewer = "auto_review"

符合條件的核准交給審查智慧體，按策略放行低/中風險、拒絕嚴重風險。 代價是額外的模型呼叫，會多花額度。

或者用細粒度策略，讓某些類別保持互動式、其餘自動拒絕：

toml
approval_policy = { granular = { sandbox_approval = true, rules = true, mcp_elicitations = true, request_permissions = false, skill_approval = false } }

--yolo 能用嗎 ​

能用，但想清楚在哪用。在一個隨時能扔掉的容器裡沒什麼問題； 在你自己的開發機、在有未提交改動的倉庫裡用，就是拿工作賭它這次不會跑錯指令。

真需要放開，先把工作放進 Dev Container 或 Git 工作樹。

上下文與工作階段 ​

聊著聊著它就變笨了 ​

上下文被中間產物填滿了。按這個順序想：任務換了就開新工作階段； 日誌和探索結果主執行緒不需要就拆給子智慧體； 約定每次重講就寫進 AGENTS.md；確實是長任務，才去調壓縮閾值。 詳見 快速上手 06。

怎麼接著上一次的工作階段 ​

bash
codex resume                          # 交互式
codex exec resume --last "..."        # 非交互式，接最近一次
codex exec resume <SESSION_ID> "..."  # 指定会话

子智慧體會繼承我的權限設定嗎 ​

會，而且是執行時覆蓋優先。你在工作階段裡用 /permissions 改過的設定、 甚至 --yolo，啟動子智慧體時會重新應用，即使自定義智慧體檔案裡設了別的預設值。

所以要限制子智慧體，得先把父級輪次的權限選對。

團隊使用 ​

同事那兒的行為跟我不一樣 ​

先查這三件事：

  1. 專案信任了嗎？ 不信任的話 .codex/ 層（配置、鉤子、規則）整個跳過。
  2. 他的 ~/.codex/config.toml 裡有什麼？ 使用者配置優先順序低於專案配置，但仍會生效。
  3. 他敲了什麼指令列標誌？ CLI 標誌優先順序最高，蓋過所有配置檔案。

優先順序從高到低：CLI 標誌 → 專案配置 → 配置方案 → 使用者配置 → 系統配置 → 內建預設值。

怎麼禁止團隊用 danger-full-access ​

管理員下發 requirements.toml，用權限配置方案：

toml
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

不在允許列表裡的就用不了。見 進階 05。

CI 裡怎麼放 API 金鑰 ​

如果工作流會簽出或執行倉庫控制的程式碼，別把金鑰設成作業級環境變數—— 構建指令碼、測試、依賴鉤子都能讀到。

GitHub Actions 上用官方的 openai/codex-action，別自己裝 CLI 再傳金鑰。 更好的做法是把生成補丁和開 PR 拆成兩個作業：拿金鑰的沒寫權限， 有寫權限的看不到金鑰。完整例子見 案例 03。

關於本站 ​

「官方文件」區的內容是你們翻譯的嗎 ​

不是。OpenAI 自己同時維護 zh-Hans 和 zh-Hant 兩套中文文件， 本站直接抓官方對應語言的原文，沒有經過任何機器翻譯，繁體也不是從簡體轉過去的。 每一頁頂部都有回官方原文的連結。

那繁體的教程部分呢 ​

「快速上手 / 進階 / 實戰案例 / 參考」這幾十篇是我們自己寫的簡體原稿， 繁體由 OpenCC 轉換。用詞已經逐條對齊官方 zh-Hant 的譯法—— 比如「權限」保持「權限」而不是 OpenCC 預設的「權限」， 「外掛程式」寫全「外掛程式」，「工作階段」用「工作階段」。 對照表在 scripts/i18n-terms.mjs。

內容多久更新一次 ​

映象靠 npm run fetch 重新抓，不是即時的。產品更新很快， 發現和官方對不上時以官方頁面為準——每頁頂部都有連結。

有些官方頁面這裡為什麼沒有 ​

兩類：一類是分割槽落地頁（比如官方的 Codex CLI 首頁）， 它們在 Markdown 孿生頁裡被壓成了沒有層級的卡片文案，程式碼塊全丟了， 映象過來只會誤導人，所以跳過，本站用自己寫的分割槽索引代替； 另一類是內容由前端元件渲染、Markdown 里根本沒有正文的頁面（比如官方術語表）， 這類我們自己重寫了一份，見術語表。

非官方社群教程 · 「官方文件」區為 learn.chatgpt.com 中文原文映象 · 以官方頁面為準

Copyright © 2026 Codex 中文手冊