openai / openai/codex-plugin-cc
feat: allow selecting a Codex profile for companion-launched jobs
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 33.3k
- Forks
- 2.3k
- PR merge metrics
- No merged PRs in 30d
Description
Problem
codex-plugin-cc spawns the underlying codex CLI (via scripts/codex-companion.mjs → scripts/lib/codex.mjs) without propagating any profile selection. All companion-launched jobs (setup / review / adversarial-review / task / ...) run against whatever sits at the top of ~/.codex/config.toml — either the global default fields or the top-level profile = "..." shortcut.
A user who maintains several profiles in config.toml (e.g. one per provider / endpoint, or a dedicated "review" profile with a different reasoning effort) cannot point a single Claude Code session at a non-default profile without editing their global config. The plugin UI has no way to say "for this session, use [profiles.tmp]".
Current behavior
node codex-companion.mjs --helpexposes--modeland--effort, but no--profile.- Source grep confirms:
scripts/has zero references toprofile/--profile/CODEX_PROFILE. The childcodexinvocation never receives-p <name>or-c profile=<name>. - Codex CLI itself does support
-p <name>, top-levelprofile = "..."in config.toml, and-c profile=<name>overrides (https://developers.openai.com/codex/config-advanced).
Workaround (limited)
Set profile = "<name>" at the top of ~/.codex/config.toml. That works globally but:
- It is a global switch, not per-repo or per-session.
- It conflicts with users who want different profiles for
/codex:review,/codex:task, or directcodexTUI invocations. - Project-level
.codex/config.tomlhelps, but requires scattering TOML files across target repos.
Proposed
Let codex-companion.mjs forward a profile selector to the spawned codex process. Two touch points, both additive:
- CLI flag:
--profile <name>onreview/adversarial-review/task/setup. When present, the companion passes-p <name>(or-c profile=<name>) tocodex. - Env var:
CODEX_COMPANION_PROFILE. When set and no explicit flag, use it as the default for companion-launched jobs.
Neither changes behavior for existing users — both are opt-in.
Why this matters
For skill chains that hand off to codex-plugin-cc (e.g. an agentstack-style agentstack:review → /codex:review handoff), being able to say "this repo uses profile X" at the plugin layer removes a whole class of config-edit churn when users juggle multiple model providers or reasoning-effort presets.
Related
- upstream:
openai/codex#17533—reviewcommand doesn't honor custom profiles (different layer but symptomatic of the same gap) - this repo: #167 (sandbox mode as env var), #213 (user-level defaults for companion config) — adjacent UX asks
Alternative considered
A generic pass-through: codex-companion.mjs review -- -p tmp ... that forwards everything after -- to codex. Simpler, more flexible, less discoverable. Combinable with the flag above.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in scripts/codex-companion.mjs, then follow the child-process invocation in scripts/lib/codex.mjs and inspect how arguments and environment defaults are handled. Trace the setup, review, adversarial-review, and task entry points, and verify the help output. Done means an explicit profile and the CODEX_COMPANION_PROFILE fallback reach the spawned codex process without changing existing behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- cli, developer-experience
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100