Finding · codex
Codex: Provider-Native Long-Horizon Work Is Moving Into the CLI
What Changed
Codex CLI release 0.128.0, published April 30, 2026, made persisted /goal
workflows a first-class surface with app-server APIs, model tools, runtime
continuation, and TUI controls for creating, pausing, resuming, and clearing
goals.
The same release expanded permission profiles, sandbox profile selection, active-profile metadata, plugin marketplace workflows, bundled hooks, external agent session import, and MultiAgentV2 controls.
Recent follow-on commits in the sprint window continued the same direction: plugin share access controls, hook trust metadata, model/reasoning metadata in MCP turns, cloud executor registration, selected-environment process routing, and Linux sandbox hardening.
Operator Consequence
Codex is becoming less like a stateless terminal agent and more like a provider-native agent environment: goals, permissions, plugins, imported sessions, multi-agent execution, turn metadata, and hosted/cloud executor surface area are all becoming normal.
Operators should use those provider-native capabilities where they are strong, but should not let them become the only durable record of work.
Bitter Implication
Bitter should not clone /goal. It should learn to wrap and receipt it.
The adapter contract should preserve:
- which Codex goal or imported session governed the run
- which permission profile and sandbox profile were active
- which plugin or hook surfaces were enabled
- which external agent session was imported
- which multi-agent configuration was used
- which evidence crossed back into Bitter receipts and wake packets
Signal
Provider-native long-horizon state is now a real worker capability. Bitter's durable asset is the operator-owned loop around that state: charter, authority, evidence, verification, memory, replay, and next action.