[Bug] provider_cli Codex ACP rejects model option with ChatGPT login

[cmt-t]

Bug description

A Paca provider_cli agent using Codex CLI authenticated with a ChatGPT subscription cannot start a conversation when a model is configured. The conversation fails before the first model response with:

Failed to set ACP model option: Invalid params

The same authenticated Codex CLI accepts the model when invoked directly, so this appears to be a Paca/Goose/codex-acp compatibility issue rather than an authentication or model-entitlement issue.

Environment

• Paca: v0.18.2
• Deployment: Docker Compose on ARM64 Linux
• Agent type: provider_cli
• CLI provider: codex
• Codex CLI: 0.159.2
• Auth mode: ChatGPT subscription login (codex login --device-auth)
• Agent Runner image: ghcr.io/paca-ai/paca-agent-server-goose:0.18.2
• codex-acp is present in the environment image

Reproduction

1. Create a Paca project-scoped provider_cli agent with cli_provider=codex and a static environment.
2. Authenticate inside that environment with:

   codex login --device-auth

3. Verify locally:

   codex login status

   Result: Logged in using ChatGPT.
4. Directly run:

   codex exec --model gpt-6-luna --sandbox read-only --skip-git-repo-check --ephemeral "Responda somente MODEL_OK"

   Result: successful response (MODEL_OK). gpt-5.5 also succeeds.
5. Start a conversation through the Paca UI/API using the same static environment.

Actual behavior

The Agent Runner logs:

conversation finished ...

The conversation event contains:

Ran into this error: Request failed: Failed to set ACP model option: Invalid params.

This occurs with:

• gpt-6-luna
• gpt-5.6-luna
• gpt-5.6-luna-900k

Leaving cli_model empty and setting model = "gpt-6-luna" in /home/goose/.codex/config.toml still produces the same ACP model-option error when the conversation is started through Paca.

Expected behavior

The Paca provider_cli Codex agent should either:

1. start successfully using the model from the Codex CLI configuration; or
2. pass a model identifier in the exact format accepted by the installed codex-acp; or
3. return a more specific compatibility error explaining which ACP/model option is invalid.

Questions

• Is v0.18.2 expected to work with Codex CLI 0.159.2 and its codex-acp provider?
• Does the provider_cli adapter need to omit the ACP model option for Codex and let config.toml choose the model?
• Is there a required Codex CLI/codex-acp version or image tag that should be pinned?
• Is there a documented workaround or a fix available on master?

No API key was used; authentication was exclusively through the ChatGPT subscription login.

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔}

[cmt-t]

Verified workaround

We tested a temporary Agent Runner workaround while the ACP integration is being investigated.

Minimal change

In services/agent-runner/internal/executor/provider.go, change the Codex provider mapping from:

"codex": "codex-acp",

to:

"codex": "codex",

Then rebuild and deploy only the Agent Runner image.

Runtime configuration

The static environment must receive:

GOOSE_PROVIDER=codex
GOOSE_MODEL=gpt-6-luna

The Codex CLI is authenticated with:

codex login --device-auth
codex login status
# Logged in using ChatGPT

Result

With the raw codex provider, the same Paca conversation succeeded:

Prompt:  Responda exatamente RAW_CODEX_OK
Result:  RAW_CODEX_OK

The direct Codex CLI also accepts gpt-6-luna with the ChatGPT subscription login.

Interpretation

This workaround bypasses the failing ACP model-option path and indicates that the authentication, model entitlement, static environment, and Agent Runner lifecycle are functional. The failure is isolated to the ACP/Goose integration path used by codex-acp.

Limitation

The raw provider may not forward all intermediate Codex tool-call events through Goose/Paca. It is therefore a temporary compatibility workaround, not an equivalent replacement for the ACP provider.

A likely permanent fix would be to make the Codex ACP integration avoid the unsupported model-option negotiation, or to pin/update the compatible Goose/codex-acp versions while preserving model selection through the Codex configuration/runtime.

[pikann]

Hi @cmt-t ,

I checked and verified that the Codex Provider CLI agent type works with the gpt-6-luna model. However, there was a bug in the model editing feature

Specifically, setting an invalid model name on the initial attempt causes subsequent requests to fail with the error: "Request failed: Failed to set ACP model option: Invalid params."

I have submitted a fix in PR #534. To confirm that this completely resolves the issue, could you please re-test this after the next release?

I'll be releasing the updated version shortly

Thank you very much for your detailed feedback, it was extremely helpful!