Codex Docker multi-profile bootstrap from saved profiles

[J3m5]

Thanks for the fix in #55. The named-profile token isolation in v2.11.37 solved the main cross-profile contamination issue.

I found one remaining gap in the Docker/Compose flow for Codex multi-profile setups.

Problem

For named Codex profiles, runtime state now lives correctly in /data/codex-profiles/*.json.

But in Docker, onWatch still seems to require a bootstrap Codex token at daemon startup before it will even create the Codex provider / manager.

Relevant code paths:

• main.go
  • preflight token detection via api.DetectCodexToken(...)
  • Codex startup is still gated by cfg.HasProvider("codex")
  • Codex client / tracker / manager are only created inside that gate
• internal/agent/codex_agent_manager.go
  • once started, the manager already knows how to load profiles from /data/codex-profiles
  • and falls back to default only when no saved profiles exist

In practice, this means:

• /data/codex-profiles/*.json can already exist
• onwatch codex profile list / status still show them
• but if the container has no CODEX_TOKEN, no CODEX_HOME/auth.json, and no visible ~/.codex/auth.json
• then cfg.HasProvider("codex") stays false
• so the Codex manager is never started
• and no Codex polling happens

So saved profiles are not currently enough to bootstrap Codex in Docker by themselves.

Why this matters

For Docker/Compose, the cleanest model would be:

• main service mounts only /data
• named Codex profiles in /data/codex-profiles are enough for normal runtime
• save / refresh use a temporary auth import only when needed

Today, the practical workaround is to expose a real Codex auth home to the container just to bootstrap Codex startup. That works, but it is deployment-specific and not a good default Compose model, especially when it depends on host permissions / ACL handling.

So the request here is not for another mount-based workaround, but for Docker runtime to treat saved profiles in /data/codex-profiles as enough to start Codex normally.

Proposed fix

Two small changes would make Docker multi-profile support much cleaner:

1. Start the Codex manager if saved Codex profiles already exist in /data/codex-profiles, even when no global CODEX_TOKEN / CODEX_HOME/auth.json is present.
2. Add an explicit auth import option for profile commands for Docker/headless flows, for example:

onwatch codex profile save Plus --auth-file /import/auth.json
onwatch codex profile refresh Business --auth-file /import/auth.json

If --auth-file is omitted, the current CODEX_HOME / ~/.codex/auth.json behavior could stay as-is.

Expected Docker flow

First install:

docker compose up -d

docker compose run --rm \
  -v ~/.codex:/import:ro \
  onwatch /app/onwatch codex profile save Plus --auth-file /import/auth.json

docker compose run --rm \
  -v /path/to/business-auth-home:/import:ro \
  onwatch /app/onwatch codex profile save Business --auth-file /import/auth.json

Upgrade / normal restart with profiles already present:

docker compose up -d

No permanent Codex auth mount should be needed just to start polling existing saved profiles.