Dominik Kundel of OpenAI's Codex developer experience team presents the Codex App Server, an open-source JSON-RPC protocol that wraps the Codex agent harness and powers the Codex app, IDE extensions, and third-party clients such as those for Xcode and JetBrains. Topics include: comparing the App Server to ACP; inspecting live events between the app and server; the 120+ client messages exposed for control; sign in with ChatGPT so users bring their own subscription; layered developer instructions; dynamic and deferred tools; per-thread model and sandbox settings; shipping the binary, generating bindings, and using the Python SDK; when to use codex exec instead; and a demo of Codex running inside Doom with tools that modify the game. # Channel Presentation Observations: Codex Harness Talk **Source:** Video `01a15ca6-dcdf-78ac-9426-be68e913cf9d` **Title:** *Building on the Codex Harness — Dominik Kundel, OpenAI* **Metadata:** None supplied. All observations derive from the title and transcript. **Scope note:** This is a single video. Observations describe this material only and do not generalize to a channel. --- ## 1. Explicit Self-Description Statements the speaker makes about himself and his role: - **Name and role:** > "My name is Dom. I work uh, at OpenAI on developer experience specifically for Codex." - **Stated purpose of the talk:** > "...I want to talk to you all about how you can actually build on top of the Codex harness and hopefully make it a bit easier and less daunting for you to um, actually build your own interfaces on an on an agent harness." - **Stated tone expectation:** > "And hopefully also a little bit fun." --- ## 2. Intended Audience Evidence that the material addresses developers building agent software: - **Opening audience poll:** The speaker asks who has built their own agent harness and who finds building one "way too intimidating," signaling a developer audience with mixed experience levels. - **Venue reference:** The speaker says "we are at an AI engineer conference," which places the audience at a practitioner event. - **Technical depth:** The material assumes familiarity with concepts such as JSON-RPC, system prompts, MCP, context windows, sandboxing, and CI/CD. - **Direct address:** Recommendations are phrased for the listener's own projects, for example: > "So if you're building your own harness harness integration, your own client, you can actually leverage the same capabilities." --- ## 3. Claimed Scope What the speaker says the talk covers: - **Time frame:** > "over the next 18 minutes or so" - **Topics announced or covered:** - What the **app server** is, described as "the protocol that wraps the Codex harness" - Comparison with **Agent Client Protocol (ACP)** - Customization through **developer instructions** and **dynamic tools** - Deployment via the **Codex CLI binary** and the **Python SDK** - Differences between the **app server** and **Codex Exec** - **Deferred content:** The speaker mentions that deeper behind-the-scenes material will be covered "tomorrow in the afternoon" in another session. --- ## 4. Creator Claims vs. Demonstrated Material ### Creator Claims (stated, not independently verified in the transcript) - The Codex harness and app server are **open source**, under an **Apache 2** license. - The app server can connect to **any model provider** with a compatible Responses API, with convenience settings for **LM Studio** and **Ollama**. - The same app server powers the **Codex app**, the **IDE extension**, the **VS Code extension**, and third-party clients. - Users can **sign in with ChatGPT** and use their own subscription limits. - Developers should **ship their own version** of the harness and use **developer instructions** rather than replacing base instructions. ### Demonstrated Material (shown or described on screen) - **Live protocol inspector:** The speaker shows a custom inspector that intercepts events between the Codex app and the app server, including thread starts, configuration reads, and streamed deltas. - **Doom demonstration:** A Doom build (Electron-based, using Cloudflare's Doom Wasm renderer and FreeDoom) runs Codex inside the game. Dynamic tools expose armor, health, and weapon data. The speaker also shows a shell call returning the working directory. - **Note:** The Doom demo included control-capture issues that the speaker acknowledged and worked around. This shows a live, unedited presentation style. --- ## 5. Promotional and Persuasive Elements Observable framing that favors OpenAI's Codex product: - **Product-first recommendations:** > "...probably most of you are going to choose option two, which is you just ask Codex." - **Call to action:** The speaker invites attendees to scan a **QR code** for slides and to visit the **OpenAI booth** for questions. - **Product capability claims:** The speaker says a Visual Basic Windows client was built "largely in one shot," without a citation of evidence beyond the statement itself. --- ## 6. Presentation Style Observations - **Interactive opening:** Uses audience hand-raising to set context. - **Conversational delivery:** Frequent filler words and self-corrections appear in the transcript (e.g., "Um," "uh," "Let me do this once more"). - **Recap structure:** Ends with three explicit tips, introduced as "a three more tips just to recap." - **Humor:** Includes a self-aware "trick question" framing and an informal remark that he would not necessarily recommend writing code inside Doom. --- ## 7. Limits of This Observation - No curated metadata, channel description, or additional videos were provided. - No timestamps are present in the source, so no time-coded claims are made. - Speaker's private motivations are not inferred. # Delivery Observation — "Building on the Codex Harness" (Dominik Kundel, OpenAI) ## Tone - **Conversational and approachable.** Opens with informal audience engagement: *"All right, everyone. Hi, everyone. Um, I want to start with a quick raise of hands."* - **Self-deprecating humor** appears at natural tension points: - *"this was a bit of a trick question because if you attended the keynote yesterday, all of you should have raised your hand."* - *"I went a bit overboard and actually built a little inspector."* - *"Uh not sure if I would recommend it. Uh I think the app the Codex app is slightly better for this."* - **Reassuring toward beginners**, explicitly targeting intimidation: *"hopefully make it a bit easier and less daunting"*; *"This might seem daunting at first, but... a lot of this should feel relatively familiar."* ## Vocabulary & Recurring Phrases - **"Raise of hands"** — used three times, with an explicit apology for the repetition: *"I have one more raise of hands. I promise I'm going to give you all a break."* - **"Harness" and "app server"** — the dominant noun pair, recycled constantly to anchor the audience (*"the same harness, the same app server"*). - **"Context window pollution"** framing recurs: *"rather than polluting the overall context window"*; *"you're not polluting the context window unnecessarily."* - **Hedged enthusiasm markers:** *"actually"* and *"really"* appear with high frequency (*"how you can actually build," "you can really be creative," "the app server really shines"*). - **Casual fillers** ("um," "uh," "like") are frequent throughout, consistent with a spoken, unscripted delivery. ## Teaching Habits - **Polls the audience to calibrate content**: three separate hand-raises establish who has built a harness, who finds it intimidating, and who knows the app server. - **Anchors new concepts to known ones**: repeatedly compares the app server to ACP (*"if you've ever looked into something like agent client protocol, this is a very similar concept"*). - **Live demo over hypotheticals**, stated explicitly: *"rather than showing you a bunch of hypothetical messages, I went a bit overboard and actually built a little inspector... so we can look at some real events."* - **Progressive demo sequence**: real event inspection → customization concepts (developer instructions, dynamic tools) → a playful end-to-end demo (Codex in Doom). - **Closes with a numbered recap**: *"I have a three more tips just to recap what we talked about"* — ship your own harness, expose functions as deferred, prefer developer instructions over base instructions. - **Personal anecdotes as proof points**: *"I used it for example to build a client using um, Visual Basic... and it did it largely in one shot."* ## Communication Patterns - **"You can actually..." construction** recurs as the core persuasion move — emphasizing capability and lowering perceived barriers: *"you can just use that to spin up the app server right now," "you can even connect it to any other model provider."* - **Anticipates audience questions inline**: *"one question that came up a lot of times is what's the difference with Codex Exec"* — answered with a concrete use-case split (scripting/CI vs. comprehensive clients). - **Handles live-demo friction transparently**: *"it messed up the controls, my bad. One sec."* / *"Let me do this once more. Um I think I had some old ones buffered."* — narrates recovery rather than hiding it. - **Logistical signposting**: time-boxes the talk upfront (*"over the next 18 minutes or so"*), references a follow-up session (*"we'll cover more tomorrow in the other session"*), and ends with clear next steps (*"scan that QR code if you want to have the slides"*). ## Stability Notes - The **humor, hand-raising, and demo-recovery behaviors** each appear multiple times and look stable across the talk. - The **"three tips" recap structure** is observed once; whether it is a habitual closing pattern cannot be determined from a single video. - Evidence is drawn from one ~18-minute talk; delivery under different formats (e.g., webinars, interviews) is not observable here. # Observation Record: "Building on the Codex Harness" **Speaker:** Dominik Kundel ("Dom"), OpenAI. Attribution comes from the curated title metadata and the speaker's self-introduction in the transcript ("I work at OpenAI on developer experience specifically for Codex"). **Format:** Conference talk, approximately 18 minutes, with a live demonstration. **Source basis:** Transcript only. All positions below are as expressed by the speaker. --- ## 1. Core Thesis The speaker's central position is that developers can build their own agent interfaces on the **Codex harness** through the **Codex app server**, and that doing so is less daunting than building an agent harness from scratch. > "I want to talk to you all about how you can actually build on top of the Codex harness and hopefully make it a bit easier and less daunting for you to um, actually build your own interfaces on an on an agent harness." --- ## 2. Claims About the App Server ### 2.1 Definition - **Position:** The app server is "the protocol that wraps the Codex harness." - **Stated comparison:** It is "a very similar concept" to **Agent Client Protocol (ACP)**. The speaker says differences will be discussed in a later session, so no detailed comparison is offered here. ### 2.2 Protocol Style - **Position:** It is a **JSON-RPC-style** protocol. - **Scope of use:** The speaker says it powers first-party interfaces (the Codex app, the IDE extension, the VS Code extension) and third-party ones. ### 2.3 Named Third-Party Integrations The speaker says these are "all powered by the same harness, the same app server": - Xcode - JetBrains IDEs - Open-source projects, including "Theos T3 Code or Remote X" (see Section 9 on transcript quality) - A Claude Code plugin that lets Claude Code users invoke Codex for code review or task handoff ### 2.4 Exposure of Capabilities - **Position:** The protocol exposes "anything that is really in the app," including streaming and file search, and these are passed between app server and app. - **Quantitative claim:** "over 120" client messages, which the speaker says are continuously expanded. - **Examples of message categories:** - Initialization and client-specific configuration - Thread modifications and turns - Setting a goal (for implementing a custom "goal mode") - Listing plugins - File search and file system modification --- ## 3. Licensing and Openness - **Position:** Both the Codex harness and the app server are **open source**. - **License:** Apache 2.0. The speaker says developers should "feel free to fork it." - **Model flexibility:** The speaker states the harness can connect to "any other model provider as long as they have a responses API capable compatible API," with convenience settings for **LM Studio** and **Ollama**. - **Recommended learning path:** Ask Codex to read the repo. --- ## 4. Customization Mechanisms ### 4.1 Developer Instructions - **Position:** Developer instructions are the recommended way to customize behavior. - **Mechanism:** They append to the Codex system prompt rather than replacing it. - **Reasoning stated:** This preserves "all of the work that we put into tweaking the prompts for the individual models" while still allowing use-case customization. - **Example:** The Codex app itself is built this way, since it has app-specific functionality beyond the IDE extension or CLI. ### 4.2 Dynamic Tools - **Position:** Developers can define custom functions for the agent. - **Alternatives acknowledged:** MCP and similar approaches "you would do in ACP." - **Deferred loading:** Tools marked deferred are not injected into the system prompt. Instead, Codex uses a **tool search** tool to locate them. - **Stated reason:** Avoiding "polluting the overall context window." The speaker defers detailed explanation to a later session. ### 4.3 Per-Thread Configuration - **Position:** Configuration can be modified per thread. - **Examples given:** - Changing the model provider - Choosing a different model - Fine-grained sandbox control, including network access and writable files ### 4.4 Configuration Control Relative to ACP - **Position:** The app server offers "more control over the individual parts of the harness" than ACP, which the speaker describes as "a more generic protocol." --- ## 5. Authentication and Billing - **Position:** Developers can offer **"sign in with ChatGPT"** within their own app. - **Stated consequence:** End users can use their own ChatGPT subscription, and usage counts against their Codex usage limits rather than the developer's. - **Example cited:** T3 Code or similar tools. --- ## 6. Distribution and Versioning ### 6.1 Binary Source - The app server ships as part of the **Codex CLI** and is the same binary. - The Codex app bundles the binary, and it "changes with every version of the app." ### 6.2 Windows Specifics - Windows ships **two binaries**: a Linux-compiled build (for WSL mode) and a Windows-native build. ### 6.3 Recommendation: Ship Your Own Harness - **Position:** Developers should bundle their own harness version. - **Reasoning:** - Relying on the user's installed CLI leads to breaking changes and experimental-feature drift. - Users may not have updated to the required version. - **Acknowledged limitation:** The speaker notes that breaking changes are minimized but not absent. The protocol "regularly changes between versions." ### 6.4 Code Generation - Codex can generate **TypeScript bindings** and a **JSON schema** for a specific app server version, which the speaker calls "incredibly helpful." --- ## 7. Transport and Integration Paths ### 7.1 Transports - **Standard I/O (STDIO)** or **WebSockets**. - **Speaker's position:** "It's going to depend on your use case," and the easiest way to decide is to ask Codex. ### 7.2 Integration Options | Option | Speaker's description | |---|---| | **1. Python SDK** | Recently released; handles lifecycle management; simplifies sign-in with ChatGPT; familiar interface | | **2. Ask Codex** | Codex is "incredibly good at implementing this protocol"; point it at the documentation, though "in most cases, you don't even have to do that" | - **Speaker's prediction:** Because this is an "AI engineer conference," the audience will "probably" choose option two. --- ## 8. Demonstrations and Examples ### 8.1 Live Inspector - The speaker built an inspector to intercept events between the Codex app and the app server. - He showed thread starts, configuration reads, new-thread events, and streaming delta messages. - He describes the messages as initially "daunting" but "relatively familiar." ### 8.2 Codex in Doom - **Architecture as described:** - An Electron app using Cloudflare's Doom Wasm renderer - Game engine mostly in C - FreeDoom game files, which the speaker says Codex modified - Input passed to the app server via Electron IPC - **Model used:** "5.5" (as stated in the talk) - **Dynamic tools demonstrated:** Retrieving armor, health, weapons, and ammo - **Shell access:** The agent called Z shell to get the current working directory. The speaker notes this runs on his machine. - **Speaker's qualification:** On writing code inside Doom, "not sure if I would recommend it" and "I think the Codex app is slightly better for this." ### 8.3 Visual Basic Windows Client - The speaker says he built a Windows-native client using Visual Basic, "largely in one shot," using the Codex build-macOS-apps plugin among others. --- ## 9. App Server vs. `codex exec` **Position:** `codex exec` and the app server serve different purposes. - **`codex exec`:** - Non-interactive - Suited to scripting and CI/CD, such as auto-fixing a PR - **App server:** - Suited to comprehensive clients with interfaces - Suited to running many Codex threads concurrently, such as custom eval harnesses or slash-goal features - Provides full harness control and avoids building custom parallelization around `exec` calls --- ## 10. Recommendations Recap The speaker offers three tips, though the recap is framed as "three more tips": 1. **Ship your own version of the harness.** This avoids reliance on user-installed CLI versions and their feature availability. 2. **Expose new functions as deferred tools.** This keeps the context window clean while keeping the functions available. The Codex app uses this for self-control, such as creating automations. 3. **Add developer instructions rather than replacing base instructions.** The speaker warns that writing a custom system prompt risks losing work on keeping prompts "in distribution" and maintaining agent performance. --- ## 11. Qualifications, Hedges, and Tensions | Topic | Expressed qualification | |---|---| | ACP comparison | Described as "very similar," but differences deferred to another session | | Protocol stability | Breaking changes are "minimized" but the protocol "regularly changes" | | Transport choice | "It's going to depend on your use case" | | Integration recommendation | Python SDK presented as "one of two" easiest options, but speaker expects most attendees to choose "ask Codex" | | Doom as an interface | "Not sure if I would recommend it" for writing code there | | Codex capability | "Incredibly good" at implementing the protocol, with "in most cases" qualifier on documentation need | | Deferred tool behavior | Explained in detail deferred to a later session | | Speaker's self-described promotional framing | The speaker is an OpenAI employee discussing OpenAI products; his assessments of Codex's capability are his own and are not independently verified in the talk | **Unresolved in the talk:** - Specific differences between app server and ACP - Detailed mechanics of tool search and the tomorrow session content - Which non-OpenAI model providers are verified to work beyond the named LM Studio and Ollama convenience settings --- ## 12. Transcript Quality Notes These items may reflect transcription artifacts rather than the speaker's intended wording. They are recorded as transcribed and not corrected: - "Theos T3 Code or Remote X" (project names unclear) - "Maddie" (referenced in the context of hardware; identity not established) - "Codex exec" and "Codex Exec" (used interchangeably) - "5.5" (model version as spoken) - "over 120 so different client client messages" (count stated as "over 120") - The talk's stated length ("18 minutes or so") and the spoken "three more tips" are recorded as the speaker stated them. # Speaker Attribution Record — "Building on the Codex Harness — Dominik Kundel, OpenAI" ## Speakers - **Dominik "Dom" Kundel (Creator/Sole Speaker)** - Self-identified: *"my name is Dom. I work at OpenAI on developer experience specifically for Codex."* - Presents a single-speaker conference talk (~18 minutes), including a live demo segment. - No other speakers appear; no narrator, host, or guests are present in the transcript. ## Roles Observed - **Conference presenter / keynote-adjacent speaker** — references a prior day's keynote: *"if you attended the keynote yesterday, all of you should have raised your hand... you probably didn't listen to Roman."* (Roman is referenced, not speaking.) - **Live demonstrator** — runs a custom "inspector" and a Doom-integrated Codex demo. - **OpenAI employee** — speaks on behalf of the Codex team ("we," "our first-party interfaces"). ## Referenced Third Parties & Sources (mentioned, not speaking) - **OpenAI / Codex team** — harness, app server, CLI, IDE extensions, Python SDK - **Roman** — keynote speaker referenced - **Maddie** — referenced as someone who runs Codex on "weird hardware" - **Named products/projects**: Agent Client Protocol (ACP), LM Studio, Ollama, Xcode, JetBrains IDEs, T3 Code, Theos T3 Code, Remote X, Cloud Code (Claude Code plugin), Electron, Cloudflare's Doom Wasm renderer, FreeDoom, Visual Basic - **Licensing/provenance facts**: Codex harness and app server are **open source, Apache 2 licensed**; compatible with other model providers via responses-API-compatible endpoints ## Promotional Segments - **Flagged**: Speaker is an OpenAI employee promoting the Codex app server as an integration platform throughout; segments on **sign in with ChatGPT**, the **Python SDK**, and the recommendation to "just ask Codex" function as product promotion, though the talk is an openly branded conference presentation. ## Availability Limits - **Comments**: No comment availability information present in transcript or metadata. - **Curated metadata**: None supplied beyond title; speaker identity comes solely from the transcript's self-introduction. - **Demo details**: Doom demo and inspector were shown live; exact visuals not available from transcript alone. All right, everyone. Hi, everyone. Um, I want to start with a quick raise of hands. How many of you have built your own agent harness? All right. How many of you um, feel like it's way too intimidating to build an agent harness? Okay, cool. So, uh, over the next 18 minutes or so, I want to talk to you all about how you can actually build on top of the Codex harness and hopefully make it a bit easier and less daunting for you to um, actually build your own interfaces on an on an agent harness. And hopefully also a little bit fun. Uh, my name is Dom. I work uh, at OpenAI on developer experience specifically for Codex. Um, and I have one more raise of hands. I promise I'm going to give you all a break. Um, but how many of you have heard of the Codex app server? All right, and this was a bit of a trick question because if you attended the keynote yesterday, all of you should have raised your hand. Um, otherwise you probably didn't listen to Roman. Um, but uh, we talked briefly about it yesterday, but we didn't really explain what the app server is. Um, so the app server is actually the protocol that wraps the Codex harness. Um, if you've ever looked into something like agent client protocol, this is a very similar concept where basically we have a protocol that allows you to directly build on top of the uh, harness and deeply integrate into it. And we'll talk a bit in the talk about what the differences are between uh, app server and ACP. Uh, the big thing here to keep in mind is both the Codex harness as well as the app server itself are open source. So, we're going to cover a couple of different things on how you can engage with it. Um, but more importantly, we're going to both dive tomorrow in the afternoon into how a couple of these things work behind the scenes, but you can also always just ask Codex to read the repo and dive really deep into it. It's Apache 2 license, so feel free to fork it, do it make it your own and have have fun with it. You can even connect it to any other model provider as long as they have a responses API capable compatible API. We even have convenience settings to connect it easily to LM Studio or Ollama. Um, in terms of how it works, the app server protocol is a JSON RPC style protocol that we actually use to power the Codex app, the IDE extension, our VS Code extension, so all of our first-party interfaces, but also third-party ones. So, if you've ever used Codex through Xcode, JetBrains IDEs, or even some open-source projects like Theos T3 Code or Remote X, you can actually all of these are powered by the same harness, the same app server. We even used it earlier this year to put Codex into Cloud Code using that same app server. So, if you're still on Cloud Code and you want to use Codex from there either to have it review your code or you know, pass off tasks to Codex to handle it, you can actually use that plugin and it uses that same app server, that same harness behind the scenes. If you've looked into things like ACP, this should seem pretty familiar. At a high level, basically the app server, the way it works is we're going to send messages between the client, which is the application you're building, and the server, which is the Codex app server, to perform different actions and receive events. But, rather than showing you a bunch of hypothetical messages, I went a bit overboard and actually built a little inspector that intercepts all of the events between the real Codex app and the Codex app server, so we can look at some real events. Let me actually switch over here to the Codex app. So, I loaded up that same inspector in the um, that browser here of the Codex app. And so, if we send a message, we're going to see here a bunch of different events coming in. This might seem daunting at first, but as you're sort of going through some of these messages, a lot of this should feel relatively familiar. So, we can look through here um Some of these might be a Let me do this once more. Um I think I had some old ones buffered, so I'm just going to start a new one. Um There we go. Also, don't mind my Codex pad up here. Uh but you're going to see like different messages from like threads being started with sort of your different configurations of what is actually happening, what project are we working on, over to configuration reads. Um Where is new threads being started, and then here's like some of your delta messages of like data actually being streamed in. And so, there's a lot of additional information that you can find here. And one of the big things that makes this protocol so flexible is that we're really exposing anything that is really in the app, a key functionality. Meaning, if we're streaming in things, we're doing file search, all of that information is actually handed back and forth between the app server and the and the app. And so, if you're building your own harness harness integration, your own client, you can actually leverage the same capabilities. In fact, we have right now over 120 so different client client messages that we continuously add more to. Um and this goes from everything from initialization where you're able to configure some of the more like specific things to your client, over thread modifications and turns, which are sort of the things that you would assume are like the most classic things. But also stuff like setting a goal if you want to implement your own version of goal mode, and listing plugins, doing all of the different other aspects that you might see in the app, all the way to things like file search and modification modifying the file system. So you can really have that full access. We also try to make it easy so that you can configure the underlying agent. And that's a bit different to ACP where it's a more more generic protocol. We can actually give you more control over the individual parts of the harness as well through the protocol. And we'll look into that in a second. The other thing that is exciting for a lot of people is you can actually if you're using this protocol, you can have sign in with chat GPT as part of that, meaning that if someone is using your app, they can still bring their own chat GPT subscription and it goes off their Codex use usage limits. So if you use something like T3 code or similar, you're actually using that. In terms of customizing the agent, the most the biggest two things that you might want to look at if you're building on top of this app server is developer instructions as a way for you to augment the instructions the system instructions of the actual app, as well as bringing tools. So with developer instructions, we're actually appending on top of the system prompt of Codex. You can look at the actual system prompt of Codex as well as in the repo. Um but we generally recommend that you actually append to that using the developer instructions. That way you're still leveraging all of the work that we put into tweaking the prompts for the individual models, while still customizing it for your specific use case of the harness. This is for example what we do when you load up the Codex app, since there's some functionality that is more specific for the app over like the IDE extension or CLI example. And then the other part of this is dynamic tools, where you can expose additional functions that you want to that you want the agent to be able to use. You could use MCP or other things similar to what you would do in like the agent client protocol, but you can also just straight up define tools, and you can actually mark them as deferred loading, which means that rather than injecting them into the system prompt, it allows Codex to use a tool search tool, which we'll cover more tomorrow in the other session, but it allows it to find these tools through tool search rather than polluting the overall context window. And then on top of that, you can even on a per thread basis modify any other configuration that you might have for your agent. So, think about setting a different model provider, choosing a different model, or even doing fine-grained control on the sandbox, like what network connections it should have access to, or what files it can modify. In terms of how you can actually use the app server, the first thing to know is that the app server actually comes as part of the Codex CLI. It's the same binary. So, if you have the Codex CLI already on your system, you can just use that to spin up the app server right now. But you can also look at how we're, for example, shipping it with the Codex app. So, the Codex app has the binary as part of the actual bundle. So, if you're looking into your installed Codex app, you should find it in the contents of that bundle, and it changes with every version of the app that you're updating. We're shipping a new version of the CLI behind the scenes. On Windows, we actually ship with two versions of the binary, both the Linux compiled one and the Windows one, so that if you're loading the app in WSL mode, it uses the Linux one, and otherwise it starts up the app server in Windows native. Um from here, you actually have a lot of different um, additional convenience functionality. One, you can have Codex generate you for that particular version of the app server, the TypeScript bindings or the um, JSON schema, which is incredibly helpful since this uh, protocol regularly changes between versions, which is also why you actually want to bundle it with your application, which is what we're doing with the Codex app, so that you have full control over what are the actual capabilities of the version that you're expecting to build against. Um, in terms of protocols, you can spin up the app server both using standard input output, so STDIO, or you can use web sockets. It's going to depend on your use case and honestly the easiest way to figure out what works better for you is probably to just ask Codex. Um, from here there's two ways that you can integrate it um, most easily. The first one is the Python SDK that we recently re- uh, released. It handles a lot of the life cycle management for you, so you don't have to deal with any of that. And then on top of that, it makes it a bit easier for you to like integrate things like sign in with ChatGPT and gives you like a familiar interface. That being said, we are at an AI engineer conference, so um, probably most of you are going to choose option two, which is you just ask Codex. So unsurprisingly, Codex is incredibly good at implementing this protocol and you largely just have to point it at um, the documentation. In most cases, you don't even have to do that, but sometimes helps it to nudge it. Um, and from here you can combine it with any of our plugins like build macOS apps um, if you want to quickly spin up something or completely go wild. I used it for example to build a client using um, Visual Basic uh, to have a like truly Windows native app um, and it did it largely in one shot. So uh, you can build really impressive applications with this in a fairly short amount of time without you having to learn all the nitty-gritty parts of of building an agent. The most interesting thing for me with this with this app server though is that you're not limited to sort of the classic agent chat interface. You can really be creative whether it's um you how you actually like trigger it inside of your UI and your existing app, whether you're running in the background, whether you put it on weird hardware like Maddie does all the time, um or if you're like me, you think about how can I shove this into video games, um and recently um I think like a month ago or so I thought about how can I actually run Codex inside of Doom rather than running Doom inside of Codex. Um and I figured let's actually do that live and I'm going to dismiss a couple of messages here. Uh so I have this Codex app Doom version and I booted up in the wrong window, so let me pull that over. There we go. So this is uh it messed up the controls, my bad. One sec. Something with this like dual monitor setup sometimes messes with the control capture, so let's hope that this works better now. Yep. Okay, so this is um an Electron app that has uh uses Cloudflare's Doom Wasm render um and it's uh so the most of the game engine itself is implemented in uh C and then it loads the FreeDoom game except that I actually manipulate had Codex change the game file, so you can see here this is rendered natively in the video game using all of their that game engine. Um and if we actually interact with it here, we're booting up Codex and again this is rendered natively inside the um actual video game and then passes the passes it to the app server using Electron's um IPC protocol. So, if we say hello here, um we can see Codex actually responding. So, this is using 5.5. The fun part though is you can actually use dynamic tools to expose additional functionality. So, naturally, um we can get um we can get all of the um armor and health, and it's calling the tools gives me all of that, or even say like all the weapons with all ammo. Um and it's calling all of the different tools. And so, it's interacting with that, but again, remember this is still an app server actually running on my machine. So, if I say like um what's the directory? It's actually calling Z shell, getting the current working directory, and you can see here it's rendering is ha it has its own workspace. So, if you want, you can write code directly into code in inside Doom. Uh not sure if I would recommend it. Uh I think the app the Codex app is slightly better for this. But, you can really have fun here and and implement your own interface. Awesome. Uh I talked with a couple of you already during the show about uh the app server, and one question that came up a lot of times is what's the difference with Codex Exec. So, if you've used the Codex CLI before, you're might be familiar with this. There's another command called Codex Exec, which spins up a non-interactive interface for you to uh pass uh to kick off tasks to Codex. This is great for scripting. If you're building a CI/CD implementation, and you want to script certain acts like auto fixing a PR, um this is a great opportunity. But, if you're trying to build like a more comprehensive client uh where you're interfacing where you're showing the agent or more importantly if you're trying to do something where you're spinning up a bunch of different Codex threads at the same time. For example, you're running you're running your own like eval harness or you want to use like slash goal. That's where the app server really shines because you have that full control over the harness and you don't have to figure out your own way of parallelizing all of the Codex exact calls rather than just sending off a bunch of like new thread events and spinning off tasks that way. Before I let you all go to the keynote, I have a three more tips just to recap what we talked about, things that you should keep in mind if you're using the app server. The first one is you should actually ship your own version of the harness. This will eliminate so many headaches for you if you're if you're relying on the user's installed CLI, you're going to constantly run into things from like breaking changes even though we are trying to minimize them, but if you're relying on experimental features that might happen. But you also don't have to worry about whether a user has actually updated their version and has the latest feature that you want to use or have them nudge them updating it. So ship your own version of the harness. The other part is you should absolutely expose new functions as part of your interface. We do this with a Codex app, for example, for it to be able to control itself as part of the Codex thread, like spinning up automations, etc. But mark them as deferred. That way you're not polluting the context window unnecessarily with all of the different additional functions that you're adding and instead still have them available for the agent without necessarily confusing it. And if you are changing the instructions, try to start with over like adding developer instructions rather than changing the base instructions. It might feel like you want to immediately rush to I'm going to write my own system prompt, but there is a lot of different things that we constantly have to think about when we're building a harness to make sure that the actual prompt is in distribution and make sure that the agent performs well. And you're losing out on all of that if you're actually jumping in and like writing your own system prompt. So be careful there uh if you're doing that. With that, thank you so much. Uh thanks for taking your time. Feel free to scan that QR code if you want to have the slides and I'll be around for uh like the next 15 minutes at the Open AI booth if you want to ask me any questions there. Thank you so much. \>\> \[music\]