openai / openai/codex-plugin-cc

feat: allow selecting a Codex profile for companion-launched jobs

Open
#251 1 comment 2 reactions 0 assignees View on GitHub

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.mjsscripts/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 --help exposes --model and --effort, but no --profile.
  • Source grep confirms: scripts/ has zero references to profile / --profile / CODEX_PROFILE. The child codex invocation never receives -p <name> or -c profile=<name>.
  • Codex CLI itself does support -p <name>, top-level profile = "..." 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:

  1. It is a global switch, not per-repo or per-session.
  2. It conflicts with users who want different profiles for /codex:review, /codex:task, or direct codex TUI invocations.
  3. Project-level .codex/config.toml helps, 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:

  1. CLI flag: --profile <name> on review / adversarial-review / task / setup. When present, the companion passes -p <name> (or -c profile=<name>) to codex.
  2. 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#17533review command 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.