标签：#codex

I began this investigation with a specific question: can Codex autonomously add, modify, and delete its own memories? The product documentation already says that it has memory. What I wanted to know was who actually decides what survives. When an old chat contains a useful build command, does deterministic application code copy it into a database? Does the active coding model call a memory tool? Does another model summarize the chat later? When the command becomes obsolete, is the old fact overwritten, invalidated, aged out, or simply left where future agents may still find it? Those questions led to a more interesting result than a feature checklist. Codex has a genuine cross-session memory subsystem, but its behavior is split between model judgment and deterministic lifecycle code. Models decide what a rollout means and how durable guidance should be rewritten. Runtime code decides which rollouts are eligible, which evidence remains in the working set, when old records are deleted, and when the consolidation model is allowed to run. That makes the short answer precise: With local memories enabled, Codex can autonomously add, modify, merge, and remove persistent memory without a user approving each write. User-requested corrections follow a separate append-only note path, while retention, thread deletion, and reset provide additional forms of forgetting. The rest of this article explains why each word in that answer matters. This analysis is pinned to OpenAI Codex commit 8444cf63b50a8a88521e0d2970d49f659b48eac7 , checked on August 25, 2026. The feature is marked stable in that source tree but remains off by default, so this describes implemented behavior, not behavior every Codex user is currently receiving. Key Takeaways Codex local memory is a background two-model pipeline. One model extracts reusable material from each eligible rollout. A second model consolidates those outputs into a global file-based memory workspace. The LLM owns semantic CRUD, but not lifecy

OpenAI's Codex CLI is a genuinely good coding agent, but out of the box it runs OpenAI models on OpenAI billing. Sometimes you want Claude Opus for a gnarly refactor, Kimi K2.7 Code for cheap long sessions, or a model served from EU infrastructure because your client asks where tokens go. What most people miss: Codex has custom providers built in. It speaks the Responses API to whatever base_url you give it, so any gateway that implements the Responses API can act as the router behind Codex. No forks, no proxies, one config block. Option 1: the config block Codex reads ~/.codex/config.toml . Add a provider and a profile: [model_providers.opper] name = "Opper" base_url = "https://api.opper.ai/v3/compat" env_key = "OPPER_API_KEY" wire_api = "responses" [profiles.opus] model = "anthropic/claude-opus-4-7" model_provider = "opper" [profiles.kimi] model = "moonshot/kimi-k3" model_provider = "opper" I'm using Opper here (disclosure: I work there), an EU-hosted gateway with 700+ models behind one API key that implements the Responses API. Export the key and launch with a profile: export OPPER_API_KEY = "your-key" codex --profile opus That's the whole router. Yes, that means Claude running inside OpenAI's own CLI, which never stops being funny. Option 2: one command If you don't want to touch config files, the Opper CLI writes exactly that block for you (with sentinel markers, so it never clobbers your existing config and can cleanly remove itself): npm install -g @opperai/cli opper launch codex It detects Codex (installs it with --install if missing), configures the provider, and starts it with preset profiles. opper launch codex --model moonshot/kimi-k3 picks a model at launch. Which models actually make sense in Codex openai/gpt-5.3-codex : the model Codex was built for, via API billing. Honest note: if you already have a ChatGPT plan, Codex is included there and that's the cheaper path for this one model. The router play is for everything else. anthropic/claude-opus-4-7

Once you use Claude Code or Codex for real work, a total usage number stops being enough. You want to know which change consumed it. I did not build agent-cost because I had missed the existing token and cost trackers. I knew about multi-agent reporting CLIs, local dashboards, and OpenTelemetry-style observability stacks. I had even built a similar view in Notion before. The problem appeared when I tried to use that kind of reporting in an operational workflow. I needed agent logs to stay on the machine. I wanted a small runtime dependency surface, custom metrics I could audit, and a machine-readable result that another tool could consume. Most importantly, I needed session measurement and task attribution to remain two different claims. I did not need another universal dashboard. I needed a boundary underneath the dashboard that could answer: is this number supported well enough to enter task accounting? A measurement layer below the UI Different tools optimize for different jobs. A broad CLI such as ccusage is useful when coverage across agents matters. Local interfaces such as token-tracker or AgentMeter are a better fit for visual exploration of projects, sessions, subagents, and tools. An OpenTelemetry stack is the natural choice for fleet-level metrics, logs, and traces. Those are not inferior versions of agent-cost . They serve different use cases and trust models. The layer I wanted looked like this: local observations -> auditable normalized facts -> explicit pricing status -> caller-selected sessions -> task-attribution policy -> optional dashboard / Notion / spec-lane agent-cost reads logs that Claude Code and Codex CLI have already written locally. It normalizes each usage event into a fact with a model, token kind, timestamp, and count. At runtime it makes no network calls and declares no Python runtime dependencies. Its price catalog has a version and SHA-256 digest, both carried into machine-readable output. That “zero-network” claim is deliberately l

"You're spawning a fresh codex exec for every single call? Just run the app-server and reuse a thread. The prompt cache alone will pay for it." That sentence sounds so obviously right that nobody ever benchmarks it. We run a small bazaar of headless AI daemons — designers, reviewers, code workers — and each one shells out to OpenAI's Codex CLI dozens of times per work item. A resident codex app-server --stdio with warm threads looked like free money. We measured it four times. The prompt cache eventually hit 86% on the turns that mattered. The pipeline got slower than the boring baseline, and 39% more expensive in raw tokens. This is the story of why, and of what app-server is actually for. The setup was deliberately minimal: no resident daemon, no pool. The server is spawned privately for one formation , runs its turns, and is killed by a context manager on the way out — success or crash. That keeps the comparison honest: same lifecycle as a subprocess, and adopting it stays a measurement problem instead of an architecture debate. Trusting the probe Before writing any integration, we cloned the actual openai/codex source and pointed a probe at a real app-server: handshake, per-turn sandbox overrides, interrupts, forks, kill-and-resume. Eight checks, all green, plus three findings you won't find in any docs: cwd and sandboxPolicy are sticky when omitted — every turn must re-state them explicitly, or turn 3 silently inherits turn 2's write access. Token usage arrives on thread/tokenUsage/updated , not on turn/completed . An empty thread that never ran a turn is never materialized — you cannot resume it later. Pre-warming a thread pool is a trap. And the seductive one: on the probe's trivial two-turn thread, turn 2 reported 15,104 cached input tokens . See? The cache works. Ship it. That number cost us three more measurement runs to un-believe. The four runs Same fixture repo, same greenfield request, one real four-stage formation each: A: codex exec (baseline) B: app

OpenAI's fancy new AI keypad will be a lot of fun for some, while many others are probably not going to touch it.

In my previous post about a cost budget advisor , I built a mechanism that checks how much quota is left before it runs anything. This time I want to take that idea one step further: instead of cycling a single Codex through jobs one after another, run several of them at the same time as a swarm. I'll walk through the actual code for a three-layer protocol where workers declared in plan.json are expanded by orchestrate-worktrees.js into a tmux session plus git worktrees, so each Codex runs in parallel without interfering with the others. The problem: running Codex serially on the same branch When you run Codex jobs one after another on a single repository, you hit issues like: A commit from the previous job changes the preconditions for the next one Task B keeps waiting until Task A finishes When a conflict happens, the "which change is correct" decision bounces back to a human Separating branches with git worktree reduces the conflict risk to zero. Combining that with tmux to launch everything in parallel is the design for this post. The big picture: a three-layer protocol plan.json ← declaration layer (what goes to which worker) ↓ orchestrate-worktrees.js ← orchestrator layer (creates worktrees, launches tmux) ↓ orchestrate-codex-worker.sh ← worker layer (runs Codex, writes artifacts) The orchestrator doesn't know about the workers, and the workers don't know about each other. Artifacts are consolidated into three files under .orchestration/{session}/{worker_slug}/ . File Role task.md Work instructions for the worker (generated by the orchestrator) status.md State: not started → running → completed / failed handoff.md Codex output + git status (written by the worker) Declaring the plan in plan.json { "sessionName" : "refactor-sprint" , "repoRoot" : "~/my-project" , "worktreeRoot" : "~/worktrees" , "coordinationRoot" : "~/my-project/.orchestration" , "baseRef" : "HEAD" , "replaceExisting" : true , "launcherCommand" : "bash ~/.claude/scripts/orchestrate-codex-worker

I pin model IDs on purpose. Floating aliases have burned me before — a silent swap under a -latest tag once changed a tool-calling detail in production and cost me a Saturday with git bisect and a coffee I didn't enjoy. So everything I run points at a dated snapshot. gpt-5-codex was one of them. Last week I finally read OpenAI's deprecations page top to bottom instead of skimming it, and there it was: gpt-5-codex , retiring 2026-07-23 , sitting quietly next to ten of its neighbors. As I write this it's July 16. That's seven days . If you pinned any of the snapshots below, consider this your heads-up. Here's the full retirement list, how to find out in about ten minutes whether you're exposed, the replacement map with the things I'd actually regression-test, and the one structural change that turned my last forced migration from scary into boring. The shutdown list (retiring 2026-07-23) Straight from OpenAI's API deprecations page . I checked each row against the source while writing this — do the same before you act on it, because dates and replacements do get revised. Retiring model OpenAI's suggested replacement gpt-5-codex gpt-5.5 gpt-5.1-codex gpt-5.5 gpt-5.1-codex-max gpt-5.5 gpt-5.1-codex-mini gpt-5.4-mini gpt-5.2-codex gpt-5.5 gpt-5-chat-latest gpt-5.5 gpt-5.1-chat-latest gpt-5.5 gpt-4o-search-preview-2025-03-11 gpt-5.4-mini gpt-4o-mini-search-preview-2025-03-11 gpt-5.4-mini gpt-4o-mini-tts-2025-03-20 gpt-4o-mini-tts-2025-12-15 computer-use-preview-2025-03-11 computer-use-preview (or gpt-5.4-mini ) Note the shape of it: the *-codex line collapses into gpt-5.5 — except gpt-5.1-codex-mini , which drops to gpt-5.4-mini — the chat-latest aliases fold into gpt-5.5 too, the two *-search-preview snapshots move to gpt-5.4-mini , and the two preview families ( tts , computer-use ) just roll to a newer dated snapshot / the undated alias. Once you see the buckets, the migration is less intimidating than the eleven-row table looks. Find out if you're exposed (about ten m

OpenAI, which is in the middle of a legal battle with Apple over hardware trade theft allegations, just released a light-up keyboard designed to be paired with its agentic coding app.

Rebranded Codex promises independent workflows that can run "for hours if needed."

The silicon race is heating up amid the struggle to keep up with demand.

Claude Code added Dynamic Workflows. Dynamic Workflows are a way to run larger coding tasks as a...

I mostly use Claude Code, but lately I've been using Codex CLI and Codex.app (hereafter "Codex") more often too. My environment is macOS. However, after I started using mise in [2026-03-29-1] , I ran into trouble because Codex wouldn't use the mise-managed Ruby, Node.js, and so on. Here's the state I was in: $ where ruby /usr/bin/ruby $ ruby --version ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25] The Solution I solved it by adding the following to ~/.zshenv : # When Codex CLI and Codex.app run commands, .zshrc's mise activate zsh doesn't take effect, # so add mise shims to PATH. if [ -n " $CODEX_SANDBOX " ] ; then PATH = ${ XDG_DATA_HOME } /mise/shims: $PATH fi Here's the state inside Codex after the change: $ where ruby /Users/masutaka/.local/share/mise/shims/ruby /usr/bin/ruby $ ruby --version ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [arm64-darwin25] Codex's Command Execution Environment Is a Sandbox I'd vaguely suspected this for a while, but it seems Codex's command execution environment runs inside a sandbox. You can spot the clues from within Codex: $ env | grep CODEX CODEX_CI=1 CODEX_SANDBOX=seatbelt CODEX_THREAD_ID=019e7806-6025-7c13-a3c6-a70d41c13905 "seatbelt" refers to Apple Seatbelt, which appears to be macOS's sandboxing mechanism. 🔗 macOSで手軽にSandbox環境を構築できるApple Seatbeltの実践ガイド しかしながら、Apple Seatbeltは公式にドキュメントを公開されておらず、非推奨とされています。一方で実際には多くのアプリケーションやツールで使用されています。 (English translation) However, Apple Seatbelt has no officially published documentation and is considered deprecated. Yet in practice, it's used by many applications and tools. I see... According to this article, Claude Code also adopts Apple Seatbelt, and I confirmed that it can be enabled with /sandbox (see the official documentation ). Coming from a background of being used to Claude Code, Codex's sandbox is hard to wrap my head around, but the following article covers it in detail. Much appreciated. 🔗 [Codex] sandbox実行の仕組みと設定方法を完全に理解する Codex also seems to r