Login to Codex did not bootstrap a default/eponymous "codex" profile

[lionello]

Like with Claude, after pressing "install and login" in the UI I expect to be able to add codex sessions, but there's not a single profile using codex.

Similarly, the codex session that does start after login is a "local" session, only accessible in the web UI (tmux) pane. For codex, after install+login we should start the codex daemon instead. This allows the user to immediately connect their devices for remote sessions. (The daemon is generic, not a single profile, since the clients decide the model/effort/… so no profile needed for this.)

[defangdevs]

Triage, reading the current code (connect_start/ensure_harness_session path added by #574, modules/src/settings-daemon.py).

What's true today

• No "codex" (or "claude") profile is ever auto-created anywhere. Profiles are files managed only through agent-box-profile/PROFILE_BIN; the connect card's post-login auto-add (feat(connect): auto-start a session right after install+login #574) writes a bare session entry with "profile": None, not a profile file. So the asymmetry you're seeing isn't "claude gets a profile and codex doesn't" in the code -- neither harness gets one from login. If you already have a claude profile it's one you (or something else) created by hand at some point, and nothing analogous ever ran for codex.
• Since Profiles, finishing touches #493 removed the bare-assistant <select> from the add-session row, a session can only be created from the UI by picking an existing profile. So on a box with no codex profile, the one codex session from auto-login is also the last codex session you can ever get from the UI -- there's no picker path left once it's used up. That part reads as a real gap, independent of the daemon-vs-TUI question below.
• For codex specifically, feat(connect): auto-start a session right after install+login #574 deliberately made the auto-added session remoteControl: false -- a real interactive TUI, not the app-server pairing daemon -- per the design call on Server/daemon mode belongs with the pseudo profiles, not as a profile field #504 ("I expect ... a codex session running"). That PR's own body flagged this as unresolved: "does the codex pairing daemon need to keep running independently of this new interactive session for phone/desktop pairing to stay usable?" Nobody answered it before merge.

What this issue is now asking

Reading your second paragraph, this reopens that exact open question, but the other way: instead of the interactive TUI #574 shipped, start the app-server daemon so a device can pair immediately -- and explicitly no profile, since the daemon is harness-generic. That's a reversal of the #504 design call from 5 days ago (pseudo-profile + interactive session), not an extension of it.

Also relevant: #159 (still open) is the onboarding-papercuts issue for that same daemon pane -- blank pane, no sign-in path, wrong login command documented -- which would still need addressing if the daemon becomes the default post-login target instead of an escape hatch.

Before I push anything

This is a real design fork, not a bug fix, so flagging rather than guessing:

1. Should install+login for codex go back to starting the daemon (remoteControl: true) instead of the TUI feat(connect): auto-start a session right after install+login #574 just shipped -- and does the TUI auto-add stay available some other way (manual "add session" once a profile exists), or does it go away?
2. If no profile is meant to exist for the daemon, does the interactive codex session (for someone who wants a plain worker, not pairing) still need a profile to be addable from the UI at all, given Profiles, finishing touches #493's picker requires one? That's the concrete bug half of this regardless of how (1) is answered.

Happy to implement either direction once (1) is settled -- just don't want to re-flip #574 on a guess five days after it shipped from your own design call.

[lionello]

@defangdevs answers to your points:

1. "add session" might need a separate pseudo-profile entry for daemon mode. It's valid to create codex profiles and selecting such a codex profile in "add session" should open the codex TUI, not a daemon. Daemon mode is inherently profile-less since the paired client decides then.
2. yes, interactive (=TUI) Codex still needs a profile (though we should prepopulate a default codex profile, ie. default model, default effort, no kick-off prompt, …)

[defangdevs]

Thanks for the answers. Opened #625:

1. Add Session now offers "codex remote control (pairing daemon, no profile)" as its own pseudo-profile entry, alongside shell. A real codex profile - and agent-box-session add --harness codex with none - now opens the TUI instead of the daemon (that was a genuine bug: both writers hardcoded remoteControl: true for every harness, so any codex profile picked from Add Session silently started the daemon, never a second TUI).
2. The auto-added post-login session now references the codex profile agent-box-profile seed (feat(profiles): a box arrives with profiles, and none of them is a default #508) already creates per installed harness - HARNESS only, no MODEL/EFFORT/prompt, which is already the "default model, default effort, no kick-off prompt" you asked for. It just wasn't being pointed at.

Left out of #625, flagged rather than guessed at: a box where codex is never in installAgents still gets neither a session nor a profile from a successful connect-card login, since the card offers codex regardless of installAgents. That's a separate design question (does a connect-only harness need a way into AGENT_BOX_AGENTS) - happy to take it on if you want it as a follow-up.