mirror of https://github.com/gnekt/My-Brain-Is-Full-Crew.git synced 2026-08-26 02:04:43 +00:00

Files

gnekt 1b9450aa03 fix: review corrections for Codex CLI adapter (PR #35 )

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>

2026-04-12 21:25:12 +02:00

2.3 KiB

Raw Blame History

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:

Call AskUserQuestion for confirmation.
Use the Skill tool for the setup flow.
Use the Agent tool for a follow-up task.

Codex CLI wording:

Use request_user_input to ask the user and wait for the reply.
Keep the setup flow in the root context by following the skill instructions directly.
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.

2.3 KiB Raw Blame History

Codex CLI Compatibility Guide

Flattened Workflow Example

Troubleshooting

2.3 KiB

Raw Blame History