Codex CLI Gets Session Archiving, Clickable Terminal Links, and Safer Remote Control

The Codex CLI has shipped a focused batch of updates that tighten up session management, make the terminal UI more usable, improve how third-party integrations connect to the agent, and harden the security model for anyone running Codex remotely. None of these are headline-grabbing model launches, but taken together they address some genuinely rough edges in day-to-day Codex workflows.

Here is what changed and why it matters.

Session Archiving: Stop Accidentally Reopening Old Work

If you use Codex across multiple projects or long-running tasks, the session picker can get crowded fast. The new /archive slash command (inside the TUI) and the codex archive / codex unarchive CLI commands let you mark sessions as archived, which removes them from the active resume list until you explicitly bring them back.

This sounds simple, but it closes a real annoyance: accidentally resuming or forking an old session when you meant to start fresh, or when another team member picks up the terminal. Archived sessions are protected from both operations until restored. Think of it as locking a completed thread so it stays reference-only.

The session picker also gets a small but useful UX improvement alongside this: renamed threads now show as name (thread-id) in resume hints, and pasted text works in the picker search box.

Clickable Links in the Terminal, Done Properly

TUI markdown now supports OSC 8 hyperlinks. OSC 8 is a terminal escape sequence standard that lets terminal emulators (iTerm2, Windows Terminal, GNOME Terminal, and others) render text as a clickable hyperlink, similar to how HTML anchor tags work in a browser.

In practice, this means that when Codex renders documentation, output, or references inside the terminal, URLs stay clickable even after the markdown has been reformatted. The update also handles a specific pain point: cramped tables that previously lost their link targets when reformatted into key/value record layouts now preserve those links correctly.

If you spend time reading Codex output or browsing references without leaving the terminal, this makes that experience considerably less frustrating.

App-Server and MCP Integration: More Capable, More Visible

For developers building integrations on top of Codex’s app-server, this update adds three things worth noting.

First, integrations can now resume a thread starting from its initial turns page, which gives clients a cleaner way to reconstruct context when reconnecting. Second, MCP server status is now surfaced with richer detail, so your integration can actually see what is happening with connected MCP servers rather than guessing. Third, codex app-server --stdio launches the server in stdio mode, complementing the existing WebSocket transport option (--listen ws://IP:PORT).

On the MCP concurrency side, read-only tools that advertise readOnlyHint can now run in parallel. If your workflow involves several read-only lookups, such as checking multiple data sources before generating a plan, those calls no longer queue behind each other. The speedup in multi-step agentic tasks can be meaningful.

Updated documentation for both app-server and exec-server now covers API-key remote registration, the stdio launch flag, runtime extra skill roots, and the new token behavior described below.

Remote-Control WebSockets Now Use Short-Lived Tokens

This is the most security-relevant change in the update. Previously, remote-control WebSocket connections used long-lived ChatGPT access tokens for authentication. Those tokens have broad scope and a long validity window, which is not ideal for connections that only need to authorize a specific remote session.

The new model issues short-lived server tokens for remote-control WebSocket handshakes. The token is sent as an Authorization: Bearer <token> header during the WebSocket upgrade. Codex enforces that remote auth tokens only travel over wss:// (TLS) connections, or ws:// for localhost-only scenarios.

Remote execution setup also now supports CODEX_API_KEY registration for approved OpenAI hosts as an additional auth path.

For teams running Codex in shared environments or exposing remote exec capabilities to other services, this change meaningfully reduces the blast radius if a token is intercepted or leaked. Short-lived tokens expire; long-lived access tokens do not.

A Few Other Things Worth Knowing

Goal continuation logic has been improved to stop when it hits a usage limit or a repeated blocker, rather than continuing to loop and consume tokens. If you have hit situations where Codex keeps retrying something it clearly cannot resolve, this should help.

Remote reliability has been shored up with automatic reconnection for stale exec-server WebSocket clients, immediate retry after auth recovery in remote control, and retry logic for remote compaction v2 streams. These are the kinds of fixes that only become visible when they are missing.

MCP dependencies have been updated to rmcp 1.7.0, keeping compatibility current.

Amazon Bedrock catalog metadata has been refreshed, including GPT-5.5 entries and the removal of unsupported open-source model entries.

The Bigger Picture

Codex CLI is OpenAI’s locally-running coding agent, available to users on ChatGPT Plus, Pro, Business, Edu, and Enterprise plans and open source for self-hosting. This update does not change what the agent can do in terms of raw capability; it makes the tooling more reliable and safer to operate at scale.

The trajectory here is toward production-grade workflow infrastructure. Session archiving, proper terminal hyperlinks, richer integration APIs, and token-scoped remote auth are all things you need when Codex stops being a personal experiment and becomes part of how a team actually ships code.

The full changelog is available at developers.openai.com/codex/changelog.