OpenAI Codex release notes: alpha 0.142 prepares safer remote execution

OpenAI Codex release notes picked up another alpha signal late on June 21: 0.142.0-alpha.10 starts carrying sandbox intent to remote exec servers. This is not a new UI button. It is closer to an operations receipt inside the plumbing, and it needs a careful read: remote commands do not suddenly become sandboxed because of this change, but Codex is starting to carry the policy that could make remote execution more consistent later.

For Swedish and Nordic teams testing OpenAI Codex with remote environments, SSH hosts, or separate build machines, that matters. It shows where OpenAI is moving the control plane: permission profile, workspace roots, network rules, and approvals should be able to travel with the work instead of staying on the machine where the prompt started.

OpenAI Codex release notes: what alpha 0.142.0-alpha.10 changes

OpenAI published the GitHub prerelease rust-v0.142.0-alpha.10 on June 21, 2026. The release body is short, but the tagged commit Carry sandbox intent to remote exec servers explains the real change: for remote execution, Codex can send the intended sandbox policy next to the native command.

Codex CLI is OpenAI Codex's coding agent in the terminal. A remote exec server is the component that can run commands on a machine other than the local Codex session. A sandbox is the boundary that decides which files, directories, and network paths a command may use. An approval gate is the stop where Codex needs human approval before crossing those boundaries.

The verified alpha.10 details are specific:

• a remote request can carry the canonical permission profile before local workspace roots are materialized into host-specific paths
• the sandbox working directory and workspace roots can travel as PathUri values
• Windows sandbox settings, legacy Landlock settings, and managed networking requirements can travel with the request
• symbolic entries such as :workspace_roots should stay symbolic across the boundary, so the remote server can bind them to its own paths

Important caveat: the commit also says the change only transports the intent today. Remote commands remain unsandboxed after this PR, just as they did after the previous step.

Source: GitHub release rust-v0.142.0-alpha.10, Carry sandbox intent to remote exec servers, @openai/codex npm registry

Why remote sandboxing matters for practical Codex workflows

OpenAI describes the sandbox as the boundary that lets Codex act autonomously without unrestricted access to the whole machine. The same documentation says sandboxing and approvals are separate controls that work together: the sandbox sets the technical boundary, while the approval policy decides when Codex must ask first.

That makes alpha.10 easy to place. If a local macOS session is talking to a Linux executor, the macOS machine should not guess how a Linux sandbox should be built. It should send the command and the intended policy. The remote side can then choose the right mechanism for its operating system.

For Hammer readers, the working rule is simple: before connecting Codex to real repositories, build servers, or internal tools, write down the permission profile, the writable workspace roots, the network access, and the approval points. Use env vars or secret managers for secrets, scoped API keys for integrations, output redaction, and audit logs for agent runs. Then remote execution becomes something you can review, not just something that happens to work.

Source: OpenAI Codex sandbox documentation, OpenAI Codex remote connections

Less token-budget noise

Alpha 0.142.0-alpha.9, published earlier the same day, has another small but relevant change. Codex stops recording automatic remaining-token messages at the 25, 50, and 75 percent thresholds. Instead, the near-compaction reminder and the explicit get_context_remaining tool remain for moments when the information is actually needed.

This is not a huge product launch. For longer Codex sessions, though, it means less prompt churn and cleaner context information: First, Current, and Previous appear as plain labels instead of being wrapped in <token_budget>.

Source: Simplify token budget context

Short example: use the new Codex feature

Human step: use the Codex project where you already test remote execution, an SSH host, or the alpha channel. Check the version and environment you are actually running before drawing conclusions from behavior.

Then paste this short prompt into Codex:

Review this Codex project as a remote-execution readiness check. Focus on where commands would need workspace write access, network access, or an unsandboxed retry. Return a short remote sandbox receipt with the intended permission profile, workspace roots, network needs, approval points, and one small test I should review next.

Good output should:

• separate intended policy from what is technically enforced today
• identify workspace roots and network needs without asking for broader access than the task needs
• call out the commands or steps that should require human approval
• give one small verifiable test point, not a large migration project

For Tool Forge work, this is exactly the kind of release note worth catching early. Not because everyone should jump to the alpha channel, but because it shows the control map you should have ready before remote agents get more responsibility.