Qwen Code 0.23.4：用 Codex executor 建立可控的 Agent 工作流

0.23.4 這次到底新增了什麼#

其中 Codex executor 是這篇的主角；它不是把 Qwen 的模型換成 Codex，而是把某一個子任務交給另一個已安裝的原生工具。

Codex executor 和一般 Qwen subagent 的差異#

一般 subagent 使用 Qwen Code 自己的模型與工具邊界；codex executor 則委派給另外安裝的 codex executable。找不到執行檔時，Qwen Code 不會自動退回自己的模型，因此 PATH 和登入狀態都是前置條件。

原生 Codex 任務的幾個邊界要先記住：

• 預設在前景執行；需要背景通知時才設定 run_in_background: true。
• Qwen Code 會以一次性的 app-server thread 執行 Codex 任務；完成後不能向同一個原生 Codex 任務送訊息或 resume，要重新建立任務。
• 原生 Codex 的進度、token 數與費用不會回報給 Qwen Code。
• 原生 executor 需要 trusted workspace，safe mode 不能啟動；支援 macOS、Linux 與 WSL，原生 Windows 啟動會在開始前被拒絕。

這表示它很適合「讀取目前 diff、做一次獨立審查、回傳結果」，但不適合被當成一個可以長期聊天和逐步接手的 Qwen 子 session。

升級前先確認執行環境#

在專案根目錄先確認兩個版本和執行檔位置：

1
qwen --version
2
command -v codex
3
codex --version

如果 command -v codex 沒有輸出，先安裝並登入原生 Codex，再回到 Qwen Code 測試。不要把 API key 寫入 agent Markdown；Qwen executor 會使用原生 Codex 自己的驗證與模型設定。

接著確認專案是 trusted workspace。若工作目錄包含 .env、部署憑證或尚未推送的私有程式碼，先建立一次性的 worktree，並把「審查」和「修改」拆成不同任務。可以參考 Git worktree 與 AI coding agent 的隔離工作流。

建立最小的唯讀 Codex review agent#

專案層級的自訂 subagent 放在 .qwen/agents/。先建立 .qwen/agents/codex-review.md：

1
---
2
name: codex-review
3
description: Review the current diff and report verified defects without editing files
4
executor:
5
  kind: codex
6
  command: codex
7
approvalMode: plan
8
background: false
9
---
10

11
Review the current diff.
12
Do not modify files, run destructive commands, or ask for broad permissions.
13
Report only reproducible defects, affected files, and the smallest verification command.

這份設定的重點有三個：

1. kind: codex 選擇原生 Codex executor；省略 executor.args 時，Qwen Code 會使用 codex app-server —stdio。
2. approvalMode: plan 讓這個審查角色先維持分析導向；提示文字是工作要求，不是作業系統層級的安全邊界。
3. background: false 讓目前 turn 直接等結果，方便第一次安裝時觀察失敗位置。

從 Qwen Code 呼叫它時，要求主 Agent 使用 codex-review 審查目前 diff，再檢查：

1
git status --short
2
git diff --check

若 review agent 找不到 Codex，先修 PATH、登入和 trusted workspace，不要立刻改成 yolo。

要寫檔時，先分清楚三種權限模式#

Qwen Code 的 agent 可以用 approvalMode 控制工具核准方式，但父 session 的寬鬆模式可能優先於 agent 本身的設定：

對需要寫入的 Codex 任務，先建立專用 worktree，明確選擇 auto-edit，再設定 runConfig.max_time_minutes 或等效的執行上限。原生 Codex 若需要額外權限或使用者輸入，Qwen Code 不會替它暫停等待確認；這正是不能把它丟進含有正式憑證的工作目錄的原因。

另外，Qwen Code 的 permissions 設定和 slashCommands.disabled 是兩件事。前者控制工具的 allow、ask、deny 規則，例如：

1
{
2
  "permissions": {
3
    "allow": ["Bash(git diff *)", "Bash(pnpm test *)"],
4
    "ask": ["Bash(git push *)", "Edit"],
5
    "deny": ["Bash(rm -rf *)", "Read(.env)"]
6
  }
7
}

互動式 CLI 可以使用 /permissions 檢視和修改規則。這層設定不能取代 worktree 隔離，也不能讓原生 Codex 變成可 resume 的長期 session；它只是把可核准的工具操作範圍縮小。

Goal、peer endpoint 與 hooks 要怎麼採用#

0.23.4 的 Goal 自動啟動適合固定邊界的背景工作，例如在 Web Shell 中先批准一個有明確 turn 和分鐘上限的檢查。不要因為省掉一次 /goal set 就移除原本的輸出、時間和檔案範圍限制。

peer endpoint 可以讓外部程式加入跨 session 訊息。若要做排程器或內部控制面，先記錄 session owner、傳送者驗證、可接受的命令和撤銷方式；這是整合設計的安全邊界，不應只因為 endpoint 存在就把它暴露到公開網路。

每個 agent 的 hooks 也要特別小心：Qwen Code 0.23.4 的文件指出，agent 執行期間註冊的 hook 會對 session 中符合條件的事件觸發，不只限於該 agent 自己的工具呼叫。因此第一版優先放安全的 logging hook，不要讓它在共享 session 中自動改寫檔案或權限。

升級後的最小驗證清單#

依序做一次即可留下可重現證據：

1. qwen —version 確認已切到 0.23.4，codex —version 確認原生執行檔在預期的 PATH。
2. 用 approvalMode: plan 的 codex-review 審查一個刻意很小的 diff。
3. 確認 review 完成後 git status —short 沒有非預期檔案。
4. 只在 disposable worktree 測試 auto-edit，限制命令、工作目錄和執行時間。
5. 用 可驗證完成的 AI coding agent 工作流 把 diff、測試命令和結果一起留下。
6. 若要依賴背景 Goal 或 Agent Board，另外測試中斷、重啟、權限拒絕和輸出遺失時的回復路徑。

這個清單刻意把「Qwen Code 升級成功」和「Codex 能安全修改正式專案」分開。前者只代表 executor 能啟動；後者還需要 worktree、權限、測試和人工 review 的證據。

結論：把 0.23.4 當成委派邊界的升級#

Qwen Code 0.23.4 新增的 Codex executor，讓原生 Codex 成為可委派的單次 Agent；Goal 自動啟動、peer endpoint 和 Agent Board 則擴大了背景工作與跨 session 整合的可能性。最穩妥的落地順序是：先確認 PATH 和 trusted workspace，再用 plan-mode review agent 驗證，最後才在隔離 worktree 以 auto-edit 執行有界的修改。

不要把 yolo、共享正式目錄或「模型回覆說完成」當成完成條件。真正可交付的結果仍然是可檢查的 diff、測試輸出和可回退的執行紀錄。

常見問題#