{
  "video": {
    "id": "shRR1e2HXMk",
    "title": "How Codex Works — Dominik Kundel, OpenAI",
    "duration": 1255,
    "upload_date": null,
    "channel": "AI Engineer",
    "source": "AI Engineer",
    "event_format": "In person"
  },
  "analysis": {
    "video_id": "shRR1e2HXMk",
    "title": "Codex, Behind the Harness — Dominik Kundel, OpenAI",
    "one_liner": "An OpenAI engineer walks through what the open-source Codex harness actually does with your message — context construction with deferred tools, sub-agents and browser use via code execution, sandboxing plus an auto-review approval subagent, WebSocket transport, /goal loops and server-side compaction — and points out most of it is available to anyone through the Responses API.",
    "summary": "Dominik Kundel traces a single Codex message through the harness: the app server protocol (UI → harness), context construction, action execution, sandboxing and approvals, and the Responses API (harness → inference). The argument is that the interesting parts of Codex are not secret harness magic — the harness is open source and in Rust, and features like tool search, apply_patch, WebSocket mode and server-side compaction are exposed in the Responses API for anyone building their own agent. He demos a TypeScript 'nano Codex' showing context assembly, an auto-review subagent judging a file deletion, and the payload difference between SSE and WebSocket mode (one item back instead of nine).",
    "key_points": [
      "Two protocols bracket the harness: the app server protocol between UI and harness (it powers the Codex app, Theo's T3 code, Remote X, a Claude Code plugin, and a demo putting Codex into Doom), and the Responses API between harness and inference; OpenAI worked with Ollama, LM Studio, Nvidia and others on an open Responses schema with a governance body, so any compatible provider can plug into the Codex harness.",
      "Context construction optimizes for three things: size (more context means more contradicting information and model confusion), flexibility regardless of how many skills/plugins/MCPs are installed, and cacheability for cost. Two concrete mechanisms: deferred tools that stay out of the context window until reached via tool search, and capping the available-skills list at 2% of the max context window, shrinking descriptions as it grows.",
      "Since GPT-5.4 any tool can be marked deferred-loading in the Responses API, with either OpenAI's built-in tool search or your own discovery implementation.",
      "Async actions use a spawn agent tool plus a send input tool to message, wait for, or shut down sub-agents; the same concept powers background terminals (spin one up, send data via stdin, wait a specified time).",
      "Computer use moved from the 2024-era one-action-at-a-time tool to code execution: the agent scripts its own interactions in JavaScript or Python. Browser use is a persistent Node REPL kept across turns where the model writes Playwright code against a Chromium instance — it can read one page's structure, then write a script to scrape subsequent pages.",
      "File editing: every model since GPT-5 is trained on an apply_patch tool taking a diff (also used to create files), with a shell tool for everything else. Models reach for Ripgrep from training, so the harness ships Ripgrep if you don't have it; on Windows the model was trained to write PowerShell natively.",
      "Sandboxing is Seatbelt on macOS, Bubblewrap on Linux, and a purpose-built open-source Windows sandbox in the same repo (David's article explains why the Windows alternatives didn't work).",
      "Auto review attacks approval fatigue without full-access risk: when a sandboxed action tries to escalate, a separate read-only subagent — which cannot spawn subagents — gets the transcript, the tool calls, user-authorization context and a risk taxonomy, and judges authorization level, impact and what to do. Applies to file system and network actions alike (curling Google to check connectivity is fine; uploading a file may not be).",
      "GPT-5.3 Codex Spark on Cerebras at 1,000 tokens/sec made network, not inference, the bottleneck; WebSocket mode replaces SSE/HTTP with a persistent stateful connection that sends only what changed — e.g. just the tool call result instead of all nine items.",
      "/goal works by injecting a continuation prompt containing your objective each turn until the model itself calls the update plan/update goal tool declaring the goal achieved. Auto compaction, introduced late last year, triggers server-side in the way the model was trained on and replaces the context window with one containing a compaction item."
    ],
    "takeaways": [
      "Treat the Codex harness repo (Rust, open source) as a blueprint or a base to fork — and ask Codex itself about its internals, since the harness changes with each model release.",
      "You don't need the Codex harness to get its best features: tool search / deferred tools, apply_patch, WebSocket mode and server-side compaction are all callable through the Responses API from your own agent.",
      "Budget your context deliberately — mark rarely-used tools (especially MCP tools) as deferred and cap the variable-size parts like skill listings as a fraction of the context window, rather than letting installs grow the prompt.",
      "For computer/browser automation, give the model a persistent code-execution REPL and let it script Playwright rather than exposing one discrete action per call.",
      "Write /goal prompts as concrete, verifiable objectives instead of full essays, because the loop only ends when the model can detect the goal is met.",
      "Don't reach for full-access mode to escape approvals — a read-only reviewing subagent with the transcript and an authorization/risk rubric can auto-approve the unpredictable-but-fine actions while still catching data exfiltration."
    ],
    "topics": [
      "agents",
      "codex",
      "harness",
      "context-engineering",
      "sandboxing",
      "tool-use",
      "computer-use",
      "responses-api"
    ],
    "tools": [
      "Codex",
      "OpenAI",
      "Responses API",
      "chat completions API",
      "GPT-5",
      "GPT-5.4",
      "GPT-5.3 Codex Spark",
      "Cerebras",
      "Ollama",
      "LM Studio",
      "Nvidia",
      "T3 code",
      "Remote X",
      "Claude Code",
      "Doom",
      "Rust",
      "TypeScript",
      "Playwright",
      "Node",
      "Chromium",
      "Ripgrep",
      "PowerShell",
      "Seatbelt",
      "Bubblewrap",
      "MCP",
      "apply patch",
      "WebSockets"
    ],
    "quotes": [
      {
        "text": "We talked about how we're building the context, but an agent really only becomes an agent if it performs actions.",
        "at": "07:03",
        "url": "https://www.youtube.com/watch?v=shRR1e2HXMk&t=423s"
      },
      {
        "text": "for available skills, we actually cap the available skills list at 2% of your context total like maximum context window. And that means that if it gets longer, we're reducing slowly the amount of like description that we're putting in there.",
        "at": "06:19",
        "url": "https://www.youtube.com/watch?v=shRR1e2HXMk&t=379s"
      },
      {
        "text": "we realized that with all of these tool calls and the interactions, inference was no longer the bottleneck. It was actually the network.",
        "at": "15:54",
        "url": "https://www.youtube.com/watch?v=shRR1e2HXMk&t=954s"
      },
      {
        "text": "most of the features that are stand out for Codex are actually features that are exposed in the responses API. So even if you want to build your own agent, you can leverage these things like tool search, apply patch, web sockets, or server side compaction.",
        "at": "19:58",
        "url": "https://www.youtube.com/watch?v=shRR1e2HXMk&t=1198s"
      }
    ],
    "words": 4321
  },
  "summary_url": "/#shRR1e2HXMk",
  "transcript": {
    "html": "/transcripts/shRR1e2HXMk.html",
    "txt": "/transcripts/shRR1e2HXMk.txt",
    "vtt": "/transcripts/shRR1e2HXMk.vtt"
  }
}