codex - 💡(How to fix) Fix codex app-server hardcodes SessionSource::VSCode; no --session-source flag on the umbrella subcommand [3 comments, 3 participants]

Summary

The codex app-server subcommand (in the umbrella codex binary) hardcodes the session source to SessionSource::VSCode. There is no CLI flag to override this, even though clientInfo.name is honored for the originator field. As a result, any third‑party host that embeds Codex via codex app-server --listen stdio:// produces sessions that:

• carry a faithful originator (e.g. multica-agent-sdk), but
• are also tagged source=vscode, which the default threadList allowlist treats as a normal interactive VSCode session.

These third‑party sessions then show up in Codex Desktop's recent/project history and, at high session rates, push real user chats out of the visible window.

The standalone codex-app-server binary already exposes --session-source (default vscode) and parses arbitrary values into SessionSource::Custom(...). The fix is to forward the same flag from the umbrella codex app-server subcommand.

Repro

1. Start Codex via the umbrella binary the way embedders do today:

   codex app-server --listen stdio://

   Pass clientInfo = { name: "my-agent-sdk", version: "..." } over the JSON-RPC handshake.
2. Inspect the resulting ~/.codex/sessions/.../rollout-*.jsonl session_meta line:

   { "originator": "my-agent-sdk", "source": "vscode", ... }

3. Open Codex Desktop. The third‑party session appears in the recent threads/project list, even though it was never a VSCode‑extension chat.

Root cause (confirmed against current main)

• The umbrella codex app-server subcommand calls run_main_with_transport_options(..., SessionSource::VSCode, ...) directly — the value is hardcoded, not read from a flag:
  • codex-rs/cli/src/main.rs (AppServerCommand invocation, ~L986)
• AppServerCommand does not declare a --session-source field:
  • codex-rs/cli/src/main.rs (AppServerCommand struct, ~L435–477) — fields are subcommand, strict_config, listen, remote_control, analytics_default_enabled, auth. No session source.
• The standalone codex-app-server binary already has the flag and parser:
  • codex-rs/app-server/src/main.rs (~L31–37): clap long = "session-source", default = "vscode", parsed via SessionSource::from_startup_arg.
• SessionSource::from_startup_arg accepts any string and folds unknown values into SessionSource::Custom(normalized):
  • codex-rs/protocol/src/protocol.rs (from_startup_arg).
• arg0‑style dispatch in codex does not alias to app-server, so calling codex under a different basename is not a workaround:
  • codex-rs/arg0/src/lib.rs.

Why hardcoding to vscode is load-bearing for the bug

The default threadList allowlist in rollout includes SessionSource::VSCode, which is why these sessions surface in Desktop in the first place:

• Default allowlist: INTERACTIVE_SESSION_SOURCES = [Cli, VSCode, Custom("atlas"), Custom("chatgpt")]
  • codex-rs/rollout/src/lib.rs (~L24–31)
• Default filter when client doesn't pass source_kinds:
  • codex-rs/app-server/src/filters.rs (~L9–15)
• Sessions whose source is not in the allowlist are dropped from threadList results:
  • codex-rs/rollout/src/list.rs (~L748–754)

So if an embedder could pass --session-source my-agent-sdk, the resulting SessionSource::Custom("my-agent-sdk") would naturally fall outside the default allowlist and Desktop would correctly hide it — same convention the codebase already uses for non‑interactive sources.

Proposed fix

Mirror the standalone binary's flag on the umbrella subcommand:

1. Add --session-source to AppServerCommand (codex-rs/cli/src/main.rs), default = "vscode" so existing VSCode‑extension behavior is unchanged.
2. Parse it with SessionSource::from_startup_arg (same as codex-rs/app-server/src/main.rs).
3. Pass the parsed SessionSource into run_main_with_transport_options(...) instead of the hardcoded SessionSource::VSCode.

This is additive, opt-in, and matches the existing convention used by the standalone codex-app-server binary. No allowlist or Desktop‑side change is required: Custom(...) sources are already filtered out of the default interactive list.

Workarounds today

• Build/install the standalone codex-app-server binary and pass --session-source <name> directly. Not viable for end users who only have the official @openai/codex distribution (which ships only codex), and Desktop's bundled codex-app-server isn't on PATH.

Context

• Reported downstream as a noisy Codex Desktop history flood when Multica agents run concurrently with the Desktop app: https://github.com/multica-ai/multica/issues/2746
• Closely related symptoms from the same root: https://github.com/openai/codex/issues/23408 (mobile Projects list scraping Multica workdirs)
• The diagnosis above was first sketched by @truffle-dev in the Multica issue thread; this report confirms it against the current upstream tree and proposes the minimal fix.