Codex: Goals, Sessions, Memories, And Sandboxes Are Becoming The Product Surface

What Changed

Codex's commit stream points toward a stateful agent control plane rather than a simple terminal prompt. The strongest evidence remains /goal: the diff-reviewed commit for TUI-side goal validation shows real UX and validation work around persistent objectives, including limits, paste handling, queued goal commands, and clearer operator guidance for longer instructions.

Around that, the same two-week window shows session ids, thread metadata in MCP turns, MCP memory work, model and reasoning metadata, plugin sharing controls, tool analytics, app-server movement, cloud executor registration, and sandbox hardening.

Operator Consequence

The question is no longer only "what did I ask Codex to do in this chat?" It is becoming "which goal, session, memory surface, plugin set, permission profile, sandbox, and executor shaped this run?"

Persistent goals are particularly important because they move a coding agent toward ultra-long-horizon work. They are useful, but they should not silently become the developer's project charter.

Bitter Consequence

Bitter should wrap Codex goals and state, not compete with them. A Bitter adapter should record active goal text or id, session id, thread metadata, memory surface, plugin state, sandbox profile, model/reasoning effort, and cloud/local executor context.

The operator owns the charter. Codex may carry a goal. Bitter should receipt the mapping.