fix(install): declare a transport in generated Codex agent role TOMLs

[dergachoff]

Problem

Codex CLI startup prints Ignoring malformed agent role definition: failed to deserialize agent role file at ~/.codex/agents/codebase-memory[-scout|-auditor].toml: invalid transport and drops all three generated roles. Fixes #1391.

Root cause

The Codex profile renderer emits [mcp_servers.codebase-memory-mcp] with only enabled_tools. Codex deserializes role files standalone and requires command or url, so every direct Codex profile since v0.9.1-rc.1 is rejected.

Fix

• Direct Codex profiles render command = "<installed binary>" and args = ["--tool-profile=scout|analysis"], mirroring the Kiro renderer; enabled_tools kept.
• The rc.1 transport-less rendering is kept as a released shape (cbm_render_graph_profile_codex_rc1), so install migrates rc.1-written files in place and uninstall removes them.
• The Codex uninstall set passes the installed binary path so exact-content ownership matching keeps working (as Kiro already does).

Validation

• test-runner: agent_profiles 10/10, cli 257/257, agent_clients 26/26, config_toml_edit 34/34 (cli lifecycle tests require no live daemon; a running one blocks uninstall quiesce)
• lint-format, lint-cppcheck, lint-no-suppress clean
• Copied the three rc.1-generated TOMLs from a real machine into a sandbox HOME: patched install -y migrated all three in place. Codex CLI 0.146.0: three invalid transport warnings before, zero after.
• Live Codex 0.146.0 session against the migrated roles: no startup warnings, the server spawned as codebase-memory-mcp --tool-profile=scout from the role's rendered transport, and the exposed tool surface was exactly the seven scout-tier tools (no query_graph/search_code/detect_changes/get_graph_schema, no mutators).

Known limit: custom --dir installs still cannot be exact-matched at uninstall (path reconstruction assumes ~/.local/bin); same pre-existing limitation as Kiro's profiles.

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[adfjadfj16-a11y]

Hola Ivan, Gracias por este trabajo detallado. He revisado los cambios propuestos y el enfoque de migración para las definiciones de roles rc.1 parece sólido. La validación que has realizado es muy completa. Por favor, procede con el merge de este pull request. Saludos cordiales, [Amaury farias] En 1 de agosto de 2026 4:13:29 p. m. GMT-04:00, Ivan Dergachev ***@***.***> escribió:

…

## Problem Codex CLI startup prints `Ignoring malformed agent role definition: failed to deserialize agent role file at ~/.codex/agents/codebase-memory[-scout|-auditor].toml: invalid transport` and drops all three generated roles. Fixes #1391. ## Root cause The Codex profile renderer emits `[mcp_servers.codebase-memory-mcp]` with only `enabled_tools`. Codex deserializes role files standalone and requires `command` or `url`, so every direct Codex profile since v0.9.1-rc.1 is rejected. ## Fix - Direct Codex profiles render `command = "<installed binary>"` and `args = ["--tool-profile=scout|analysis"]`, mirroring the Kiro renderer; `enabled_tools` kept. - The rc.1 transport-less rendering is kept as a released shape (`cbm_render_graph_profile_codex_rc1`), so `install` migrates rc.1-written files in place and `uninstall` removes them. - The Codex uninstall set passes the installed binary path so exact-content ownership matching keeps working (as Kiro already does). ## Validation - `test-runner`: `agent_profiles` 10/10, `cli` 257/257, `agent_clients` 26/26, `config_toml_edit` 34/34 (cli lifecycle tests require no live daemon; a running one blocks uninstall quiesce) - `lint-format`, `lint-cppcheck`, `lint-no-suppress` clean - Copied the three rc.1-generated TOMLs from a real machine into a sandbox HOME: patched `install -y` migrated all three in place. Codex CLI 0.146.0: three `invalid transport` warnings before, zero after. - Live Codex 0.146.0 session against the migrated roles: no startup warnings, the server spawned as `codebase-memory-mcp --tool-profile=scout` from the role's rendered transport, and the exposed tool surface was exactly the seven scout-tier tools (no `query_graph`/`search_code`/`detect_changes`/`get_graph_schema`, no mutators). Known limit: custom `--dir` installs still cannot be exact-matched at uninstall (path reconstruction assumes `~/.local/bin`); same pre-existing limitation as Kiro's profiles. You can view, comment on, or merge this pull request online at: #1408 -- Commit Summary -- * fix(install): declare a transport in generated Codex agent role TOMLs -- File Changes -- M src/cli/agent_profiles.c (82) M src/cli/agent_profiles.h (6) M src/cli/cli.c (25) M tests/test_agent_profiles.c (41) M tests/test_cli.c (54) -- Patch Links -- https://github.com/DeusData/codebase-memory-mcp/pull/1408.patch https://github.com/DeusData/codebase-memory-mcp/pull/1408.diff -- Reply to this email directly or view it on GitHub: #1408 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[adfjadfj16-a11y]

Hola equipo de DeusData, Muchas gracias por la aclaración sobre el proceso de revisión y la carga de trabajo actual. Entiendo perfectamente la situación. Me comprometo a mantener mi rama rebasada y a asegurar que el CI se mantenga en verde mientras esperan para realizar la revisión. Estaré atento a cualquier notificación. Saludos, [Amaury farias] En 1 de agosto de 2026 4:13:52 p. m. GMT-04:00, "github-actions[bot]" ***@***.***> escribió:

…

github-actions[bot] left a comment (DeusData/codebase-memory-mcp#1408) <!-- Posted automatically on every newly opened pull request by .github/workflows/pr-acknowledgement.yml EDIT THIS FILE to change what contributors are told. Blank it out to stop posting acknowledgements entirely — no workflow change needed. Keep it short, and keep it honest about what happens next. A promise of a timeline you will not meet is worse than no acknowledgement at all. Remove the review-status section below the moment it stops being true. --> Thanks for opening this — it has been seen, and it is queued. This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence. **Current review status: working through a backlog.** `0.9.1-rc.1` is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in [discussion #1144](#1144). What that means for this PR, concretely: - **It will not be closed for inactivity.** No stale bot touches pull requests here. - It may still sit a while before a human reads it. That is on us, not on you. - Older PRs are read first, so a recent one is not being skipped — it is behind a queue. Things that will genuinely speed it up whenever review does happen: - **Keep it rebased** on `main` — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended. - **Get CI green**, or say which failures you believe are pre-existing. - **Keep the change to one claim.** Bundled features and refactors get split before they get merged, which costs you a round trip. - Every commit needs a sign-off (`git commit -s`) — CI enforces DCO. If this fixes a bug, a reproduction we can run is worth more than a description of the symptom. Thanks for contributing, and sorry in advance for the wait. -- Reply to this email directly or view it on GitHub: #1408 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[DeusData]

Thank you for turning the Codex transport failure in #1391 into a focused installer change. It is now routed at high priority in 0.9.1-rc. This is an intake acknowledgement rather than approval or a merge decision; our review queue is full, so the detailed review may take a little time. For clarity, the earlier comment instructing a merge was not posted by the maintainer account or project team and should be disregarded.

[DeusData]

Thank you — this is an outstanding fix, and honestly a model for what an installer PR should look like. Root cause nailed (Codex deserializes role files standalone, so a server table without a transport drops the whole role), the fix mirrors the Kiro renderer instead of inventing a new shape, and above all: keeping the rc.1 transport-less rendering as a recognized released shape so install migrates broken files in place and uninstall still owns them — that's the lifecycle detail that separates a patch from a fix. The live Codex validation against real rc.1-generated files seals it.

And thank you for the whole #1387/#1388/#1391 report trio — the before/after evidence in each one made this release-blocking cluster far easier to work. This lands in 0.9.1.