mirror of
https://github.com/gnekt/My-Brain-Is-Full-Crew.git
synced 2026-08-27 02:25:35 +00:00
1b9450aa03
Great work on the Codex CLI integration, thanks for putting this together! After reviewing the PR against the actual Codex CLI docs and source code, I found a few things that needed fixing. Here is what changed and why. ## request_user_input is a real Codex CLI tool The adapter was removing `request_user_input` and replacing it with "ask the user directly in chat". But `request_user_input` is a native Codex CLI tool (like `shell` or `spawn_agent`). The fix: `AskUserQuestion` now maps to `request_user_input` instead of being erased, and `request_user_input` is preserved everywhere (adapter, docs, compat reference, tests). ## Fictional model names replaced with real ones The config profiles used `gpt-5.4`, `gpt-5.4-mini`, and `gpt-5.3-codex-spark`, which do not exist. Replaced with `o3` and `o4-mini`, which are the current production models for Codex CLI. ## TOML key quoting (security) `_cc_toml_quote_key` was sanitizing server names by replacing spaces with hyphens (`Google Calendar` -> `Google-Calendar`). This broke cross-platform parity because `mcp/servers.yaml` is the source of truth for all platforms. The fix: the function now properly quotes keys per TOML spec when they contain spaces or special characters, so `Google Calendar` stays as-is in YAML and becomes `[mcp_servers."Google Calendar"]` in TOML output. ## servers.yaml breaking change reverted The PR renamed `Google Calendar` to `Google-Calendar` in servers.yaml. Since this file feeds all four platform adapters, that rename would break Claude Code, Gemini CLI, and OpenCode builds. Reverted. ## TOML agent schema in migration doc was wrong The example in codex-migration.md used a nested `[agent]` / `[agent.prompt].content` structure. Codex CLI actually uses top-level keys: `name`, `description`, `developer_instructions`. Fixed the example. ## Security hardening - Path traversal guard on agent names: rejects `/` and `..` sequences - Control character rejection in TOML key quoting (newline/CR/tab) - Newline and tab escaping in all three TOML string escape functions - Fixed glob expansion risk in `_cc_capabilities_to_sandbox` (now uses `read -ra` array instead of unquoted word splitting) ## Docs and smoke matrix - codex-cli.md: fixed tool mapping table, replaced `@Agent` syntax with natural language prompts (Codex CLI does not support @ mentions), added note about dispatcher routing - codex-cli-compat.md: added Read/Glob/Grep/Bash tool mappings - README.md: added codex-cli adapter and docs to the project structure tree ## Test updates - ~15 tests updated to match the new semantics (request_user_input preserved, model names, POSIX find instead of GNU -printf) - 119/123 tests pass; the 4 remaining failures are pre-existing (bash 3.2 on macOS lacks `mapfile` and `declare -A`) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
42 lines
2.3 KiB
Markdown
42 lines
2.3 KiB
Markdown
---
|
|
exclude: [claude-code, gemini-cli, opencode]
|
|
---
|
|
|
|
# Codex CLI Compatibility Guide
|
|
|
|
Use this reference when source workflows mention platform-specific tools or recursion rules that do not map 1:1 to Codex CLI.
|
|
|
|
| Source concept | Codex CLI mapping | Notes |
|
|
|---|---|---|
|
|
| `AskUserQuestion` | `request_user_input` (native Codex tool) | Codex has this tool natively — use it to ask follow-up questions and wait for the reply. |
|
|
| `request_user_input` | `request_user_input` (same name) | This tool exists in Codex CLI — no translation needed. |
|
|
| `Skill tool` | Follow the relevant skill instructions directly in the root context | Skills stay in the main chat; do not invent a separate Skill API. |
|
|
| `Agent tool` | Use `spawn_agent` only for bounded child tasks | The root context keeps orchestration and integration decisions. |
|
|
| `Read tool` | `shell` (e.g. `cat`) | Codex has no dedicated read_file tool; use shell commands. |
|
|
| `Glob tool` / `Grep tool` | `shell` (e.g. `find`, `grep`) | Or `list_dir` (experimental). |
|
|
| `Bash tool` | `shell` | Execute shell commands. |
|
|
| `max chain depth 3` | `agents.max_depth = 1` with root-only orchestration | A child can finish one bounded task; any next step is decided back in the root context. |
|
|
| `.mcp.json` | `.codex/config.toml` | Codex MCP and profile settings live in the TOML config. |
|
|
|
|
## Flattened Workflow Example
|
|
|
|
Source workflow wording:
|
|
|
|
1. Call `AskUserQuestion` for confirmation.
|
|
2. Use the `Skill tool` for the setup flow.
|
|
3. Use the `Agent tool` for a follow-up task.
|
|
|
|
Codex CLI wording:
|
|
|
|
1. Use `request_user_input` to ask the user and wait for the reply.
|
|
2. Keep the setup flow in the root context by following the skill instructions directly.
|
|
3. If a bounded side task remains, use `spawn_agent`, then return to the root context to decide what happens next.
|
|
|
|
## Troubleshooting
|
|
|
|
- Child approvals surface in the child thread. Approve or deny there, then continue orchestration from the root context after the child returns.
|
|
- If a task would require deeper recursion, stop spawning children and flatten the next step into the root context or split the work into separate bounded child tasks.
|
|
- Codex custom agents live in `.codex/agents/*.toml`.
|
|
- Repo-scoped Codex skills live in `.agents/skills/`.
|
|
- MCP servers, approval policy, sandbox mode, and profiles live in `.codex/config.toml`.
|