Profile-backed models cause “request canceled” because --profile is passed to app-server

[mhulden]

CodexMonitor’s profile-model support currently launches the backend approximately as:

codex --profile qwen-local app-server

With Codex CLI 0.153.4, this exits immediately:

Error: --profile only applies to runtime commands and `codex mcp` ...

As a result, CodexMonitor reports the generic error “request canceled.” No request reaches the configured model provider.

This affects any profile-backed model, not only Qwen or local providers.

Environment:

• Codex CLI: 0.153.4
• CodexMonitor: current main, commit 96ee2ad
• Linux ARM64

Expected behavior:

• Profile-backed models should work in app-server mode.
• The app-server should receive the profile’s model, model_provider, and other settings.

Possible implementations:

1. Wait for/support an official Codex app-server profile mechanism, such as the proposed CODEX_CONFIG_PROFILE environment variable.
2. Translate the selected profile’s values into supported app-server -c key=value arguments.
3. Detect unsupported --profile app-server combinations and show a useful error.

A current workaround is a launcher shim that converts the Qwen profile into:

codex -c 'model="qwen3.8-flash-next"' \
      -c 'model_provider="qwen-local"' \
      -c 'model_reasoning_effort="medium"' \
      app-server

The bug is general, although our tested local shim currently handles only the Qwen profile. CodexMonitor should ideally support arbitrary profiles rather than hard-coding provider/model values.

There is also an OpenAI Codex issue tracking the missing app-server profile mechanism: OpenAI Codex issue #38104 (openai/codex#38104). Another related issue documents profile/provider problems in app-server mode: OpenAI Codex issue #23417 (openai/codex#23417).

[mhulden]

I checked this against Codex CLI 0.153.4 and current CodexMonitor main.

Findings:

• This is a real CodexMonitor bug for current Codex. CodexMonitor currently synthesizes profile-backed model entries with codexArgs = "--profile <name>", then passes those args before app-server.
• Current codex app-server --help exposes -c/--config, --enable, --disable, etc., but not --profile / -p.
• Root/runtime Codex commands still expose --profile, which is why codex exec --profile qwen ... works while codex --profile qwen app-server fails before any model request reaches the provider.

Related upstream OpenAI Codex issues:

• Support selecting a config profile for app-server and Desktop via environment variable openai/codex#38104 is the closest upstream blocker: a request for an official app-server/Desktop profile selector such as CODEX_CONFIG_PROFILE.
• app-server thread/start ignores profile model_provider from -p openai/codex#23417 is the older profile/provider app-server report. It documents app-server not inheriting model_provider from -p; current Codex versions now reject --profile for app-server outright, so the failure mode is clearer.
• Support custom model providers in app openai/codex#10867 and Model selector not available with custom LLM provider openai/codex#15138 are broader custom-provider/model-picker gaps in the official Codex app.
• Codex Desktop resolves namespaced current model against wrong list, shows "Custom" and gpt-5.3-codex openai/codex#37700 is related to custom/provider-prefixed model resolution in the Desktop picker.
• Codex Mobile remote-control tasks with custom provider disappear from thread list after refresh openai/codex#24780 is related remote-control/history behavior with custom providers.
• [App] API-key custom providers skip remote model refresh, hiding GPT-5.6 from the picker openai/codex#32119 is closed, but useful background on custom-provider model catalog refresh boundaries.
• Make config.toml profiles selectable via CLI openai/codex#4849 is related historical context for profile selection in CLI model UX.

Likely CodexMonitor-side fix:

• Do not use --profile <name> for profile-backed model picker entries while launching app-server.
• Instead, translate the selected profile's effective app-server-safe values into -c overrides, at least:
  • -c model="..."
  • -c model_provider="..."
  • -c model_reasoning_effort="..." when present
  • possibly -c model_catalog_json="..." when present
• Keep this scoped as a workaround for model/provider selection. Full arbitrary profile layering should wait for an upstream app-server profile mechanism such as #38104, because profile files can contain many keys and Codex should remain the source of truth for full config precedence semantics.

This should make custom local/profile models usable in CodexMonitor without hard-coding Qwen or any particular provider.