Desenvolvendo sobre o harness do Codex — Dominik Kundel, OpenAI

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Building on the Codex Harness — Dominik Kundel, OpenAI · Canal: AI Engineer · 17:46 · Assistir no YouTube

Tópicos: Agentes de IA, Ferramentas de desenvolvimento com IA

Resumo

Dominik Kundel apresenta o Codex app server, um protocolo open source que permite criar interfaces e integrações sobre o harness do Codex. Ele demonstra como o protocolo comunica clientes e servidor, oferece acesso a recursos do harness e permite personalizar instruções, ferramentas e configurações do agente. Também compara o app server com o Codex Exec e mostra uma integração experimental que executa o Codex dentro de Doom. Ao final, recomenda distribuir uma versão própria do harness, usar ferramentas com carregamento adiado e preferir developer instructions a substituir o system prompt.

Pontos-chave

O Codex app server é um protocolo no estilo JSON-RPC que permite criar clientes integrados ao harness do Codex.
O harness do Codex e o app server são open source, e o protocolo pode ser usado por interfaces próprias e de terceiros.
O app server expõe recursos como gerenciamento de threads, busca e modificação de arquivos e configuração do agente.
É possível adicionar developer instructions e ferramentas dinâmicas, inclusive ferramentas com carregamento adiado para evitar ocupar desnecessariamente o context window.
O app server pode ser iniciado pelo mesmo binário do Codex CLI e usado por STDIO ou WebSockets.
O Python SDK cuida de parte do gerenciamento do ciclo de vida, mas também é possível pedir ao Codex que implemente a integração.
O Codex Exec é adequado para tarefas não interativas e scripting; o app server é mais indicado para clientes completos e múltiplas threads simultâneas.
O palestrante recomenda distribuir uma versão própria do harness e acrescentar instruções em vez de substituir o system prompt.

Capítulos

Início	Capítulo	Resumo
00:12	Apresentação do Codex app server	Dominik Kundel apresenta o app server como protocolo open source para desenvolver interfaces sobre o harness do Codex.
04:53	Eventos, recursos e personalização do harness	A demonstração mostra as mensagens do protocolo e explica como configurar o agente, suas instruções e ferramentas.
09:01	Como integrar o app server	O palestrante descreve o empacotamento do binário, as opções de transporte e o uso do Python SDK ou do próprio Codex para criar clientes.
12:08	Codex dentro de Doom	Uma demonstração experimental integra o Codex a Doom e usa ferramentas dinâmicas para consultar informações do jogo e do ambiente.
14:42	Codex Exec e recomendações finais	Kundel compara o Codex Exec com o app server e recomenda distribuir uma versão própria do harness, adiar o carregamento de ferramentas e preservar as instruções base.

Citações

O app server é o protocolo que envolve o harness do Codex. — 01:15

Recomendamos que você acrescente instruções usando developer instructions. — 06:56

Você não está limitado à interface clássica de conversa com um agente. — 11:36

Distribua sua própria versão do harness. — 16:14

Conceitos e entidades

Codex app server (ferramenta): Protocolo no estilo JSON-RPC que conecta aplicações ao harness do Codex e permite interagir com seus recursos.
Codex harness (conceito): Infraestrutura do Codex que pode ser acessada e configurada por meio do app server.
Codex (ferramenta): Produto da OpenAI apresentado como agente de programação e como base para integrações personalizadas.
OpenAI (empresa): Empresa onde Dominik Kundel trabalha na área de experiência para desenvolvedores do Codex.
Dominik Kundel (pessoa): Palestrante da apresentação e integrante da equipe de experiência para desenvolvedores do Codex na OpenAI.
Agent Client Protocol (conceito): Protocolo citado como referência semelhante ao app server, mas mais genérico.
Codex CLI (ferramenta): Interface de linha de comando cujo binário também pode iniciar o Codex app server.
Codex Exec (ferramenta): Modo não interativo do Codex CLI, indicado para scripting e tarefas automatizadas.
Python SDK (ferramenta): SDK mencionado como uma forma de integrar o app server, com gerenciamento de parte do ciclo de vida.
MCP (conceito): Uma das formas mencionadas para disponibilizar ferramentas adicionais ao agente.
DOOM (ferramenta): Jogo no qual o palestrante demonstra uma interface experimental do Codex integrada por meio do app server.
LM Studio (ferramenta): Aplicação citada como opção para conectar provedores de modelos ao harness.
Ollama (ferramenta): Ferramenta citada como opção para conectar provedores de modelos ao harness.
Claude Code (ferramenta): Produto mencionado como ambiente no qual é possível usar o Codex por meio de um plugin baseado no app server.

Tradução completa (pt-BR)

00:12 Muito bem, pessoal. Oi, pessoal. Quero começar pedindo para levantarem a mão rapidinho. Quantos de vocês já criaram o próprio harness de agent? Certo. Quantos de vocês acham que é intimidante demais criar um harness de agent? Beleza. Então, nos próximos 18 minutos mais ou menos, quero conversar com vocês sobre como é possível criar algo de fato sobre o harness do Codex e, com sorte, tornar um pouco mais fácil e menos assustador criar suas próprias interfaces para um harness de agent. E, com sorte,

00:43 também um pouco divertido. Meu nome é Dom. Trabalho na OpenAI com experiência de desenvolvimento, especificamente para o Codex. E tenho mais um pedido para levantarem a mão. Prometo que depois vou dar um descanso a vocês. Quantos de vocês já ouviram falar do servidor do aplicativo Codex? Certo, essa foi uma pergunta meio capciosa, porque, se vocês assistiram à palestra principal ontem, todos deveriam ter levantado a mão. Caso contrário, provavelmente não prestaram atenção ao Roman. Mas falamos brevemente sobre isso ontem, sem explicar de verdade o que é o servidor do aplicativo. Na verdade, o servidor do aplicativo é o

01:15 protocolo que envolve o harness do Codex. Se vocês já pesquisaram algo como o agent client protocol, é um conceito bem parecido: basicamente, temos um protocolo que permite criar coisas diretamente sobre o harness e fazer uma integração profunda com ele. Na palestra, vamos falar um pouco sobre as diferenças entre o servidor do aplicativo e o ACP. O principal a ter em mente é que tanto o harness do Codex quanto o próprio servidor do aplicativo são open source. Então, vamos abordar algumas maneiras diferentes de interagir

01:45 com ele. Mas, mais importante, amanhã à tarde vamos nos aprofundar em como algumas dessas coisas funcionam nos bastidores. E vocês também podem simplesmente pedir ao Codex para ler o repo e se aprofundar nele. A licença é Apache 2, então sintam-se à vontade para criar um fork, adaptá-lo às suas necessidades e se divertir. Vocês podem até conectá-lo a qualquer outro provedor de modelos, desde que tenha uma API compatível com a Responses API. Também temos configurações convenientes para facilitar a conexão com o LM Studio ou o Ollama.

02:17 Quanto ao funcionamento, o protocolo do servidor do aplicativo é um protocolo no estilo JSON-RPC que usamos para alimentar o aplicativo Codex, a extensão para IDE, nossa extensão para VS Code e todas as nossas interfaces próprias, além das de terceiros. Então, se vocês já usaram o Codex pelo Xcode, pelas IDEs do JetBrains ou até por alguns projetos open source, como Theos T3 Code ou Remote X, todos eles são alimentados pelo mesmo harness, pelo mesmo servidor do aplicativo.

02:47 Também usamos esse servidor do aplicativo no início deste ano para integrar o Codex ao Cloud Code. Então, se vocês ainda usam o Cloud Code e querem usar o Codex por lá, seja para revisar o código ou para repassar tarefas ao Codex, podem usar esse plugin, que utiliza o mesmo servidor do aplicativo, o mesmo harness nos bastidores. Se vocês já pesquisaram coisas como ACP, isso deve parecer bem familiar. Em linhas gerais, o funcionamento do servidor do aplicativo é o seguinte: vamos enviar

03:19 mensagens entre o cliente, que é o aplicativo que vocês estão criando, e o servidor, que é o servidor do aplicativo Codex, para realizar diferentes ações e receber eventos. Mas, em vez de mostrar um monte de mensagens hipotéticas, exagerei um pouco e criei um pequeno inspetor que intercepta todos os eventos entre o aplicativo Codex real e o servidor do aplicativo Codex, para podermos ver alguns eventos reais. Vou passar para o aplicativo Codex. Carreguei o mesmo

03:50 inspetor naquela janela do navegador do aplicativo Codex. Então, se enviarmos uma mensagem, vamos ver vários eventos diferentes chegando. Isso pode parecer assustador de início, mas, conforme vocês forem analisando algumas dessas mensagens, muita coisa deve parecer relativamente familiar. Podemos dar uma olhada aqui. Algumas delas talvez… Vou fazer isso mais uma vez. Acho que havia algumas antigas armazenadas em buffer, então

04:22 vou começar uma nova. Pronto. E não reparem no meu bloco de notas do Codex aqui em cima. Vocês vão ver mensagens diferentes, como as de início de threads, com as várias configurações indicando o que está acontecendo e em qual projeto estamos trabalhando, além de leituras de configuração. Aqui aparecem as novas threads sendo iniciadas, e então

04:53 temos algumas mensagens delta, com os dados sendo transmitidos. Há muitas outras informações que vocês podem encontrar aqui. Uma das principais coisas que tornam esse protocolo tão flexível é que expomos praticamente tudo o que é uma funcionalidade importante no aplicativo. Ou seja, se estamos transmitindo dados, fazendo uma busca de arquivos, todas essas informações são trocadas entre o servidor do aplicativo e o aplicativo. Então, se vocês estiverem criando sua própria integração de harness, seu próprio cliente,

05:23 poderão aproveitar os mesmos recursos. Na verdade, no momento temos mais de 120 tipos diferentes de mensagens de cliente, e continuamos adicionando mais. Isso abrange desde a inicialização, em que vocês podem configurar alguns aspectos mais específicos do cliente, até modificações de threads e turnos, que são mais ou menos as coisas que vocês imaginariam como as mais clássicas

05:54 das funcionalidades. Mas também inclui coisas como definir um objetivo, caso queiram implementar sua própria versão do modo de objetivo, listar plugins e realizar os vários outros tipos de ações que vocês podem encontrar no aplicativo, até chegar a coisas como busca de arquivos e modificação do sistema de arquivos. Assim, vocês têm acesso completo. Também tentamos facilitar a configuração do agent subjacente. Isso é um pouco diferente do ACP, que é um protocolo mais genérico. Por meio do protocolo, podemos dar mais controle sobre as partes individuais do harness

06:25 também. Vamos ver isso em um instante. Outra coisa que anima muita gente é que, se vocês usarem esse protocolo, poderão oferecer a opção de entrar com o ChatGPT. Isso significa que, se alguém estiver usando o aplicativo de vocês, poderá usar a própria assinatura do ChatGPT, e o uso será contabilizado nos limites de uso do Codex dessa pessoa. Então, se vocês usarem algo como T3 Code ou similar, é isso que estarão usando. Para personalizar o agent, as duas principais coisas que talvez vocês queiram analisar ao criar

06:56 sobre esse servidor do aplicativo são as instruções de desenvolvedor, como uma forma de ampliar as instruções do sistema do aplicativo, e a inclusão de ferramentas. Com as instruções de desenvolvedor, acrescentamos conteúdo ao system prompt do Codex. Vocês também podem consultar o system prompt real do Codex no repo. Mas, em geral, recomendamos acrescentar conteúdo usando as instruções de desenvolvedor. Assim, vocês continuam aproveitando todo o trabalho que fizemos para ajustar os prompts para cada modelo, enquanto

07:27 personalizam o harness para o caso de uso específico de vocês. Por exemplo, é isso que fazemos quando vocês abrem o aplicativo Codex, já que algumas funcionalidades são mais específicas do aplicativo do que da extensão para IDE ou da CLI. A outra parte são as ferramentas dinâmicas, que permitem expor funções adicionais que vocês querem que o agent possa usar. Vocês podem usar MCP ou outras opções, de forma semelhante ao que fariam no agent client protocol, mas também podem simplesmente definir

07:59 ferramentas e marcá-las para carregamento adiado. Isso significa que, em vez de inseri-las no system prompt, o Codex pode usar uma ferramenta de busca de ferramentas — vamos falar mais sobre isso amanhã, na outra sessão — para encontrá-las, sem poluir a context window. Além disso, vocês podem modificar qualquer outra configuração do agent por thread. Por exemplo, definir um provedor de modelos diferente,

08:30 escolher um modelo diferente ou até mesmo ter um controle minucioso sobre o sandbox, como quais conexões de rede ele deve poder acessar ou quais arquivos pode modificar. Quanto a como usar o servidor de aplicativo, a primeira coisa que você precisa saber é que ele já vem como parte do Codex CLI. É o mesmo binário. Então, se você já tem o Codex CLI no seu sistema, pode usá-lo para iniciar o servidor de aplicativo agora mesmo. Mas você também pode ver como estamos, por

09:01 exemplo, distribuindo-o com o Codex app. O Codex app inclui o binário no próprio pacote. Então, se você procurar no Codex app instalado, vai encontrá-lo dentro desse pacote, e ele muda a cada versão do app que você atualiza. Estamos distribuindo uma nova versão do CLI em segundo plano. No Windows, na verdade, distribuímos duas versões do binário, tanto a compilada para Linux quanto a versão para Windows, para que, se você abrir o app no modo WSL, ele use a versão para Linux; caso contrário, ele inicia

09:31 o servidor de aplicativo nativamente no Windows. A partir daí, você tem várias funcionalidades adicionais para facilitar o uso. Primeiro, você pode pedir ao Codex que gere, para aquela versão específica do servidor de aplicativo, os vínculos de TypeScript ou o esquema JSON. Isso é extremamente útil, já que esse protocolo muda regularmente entre versões. Por isso, também é melhor incluí-lo no seu aplicativo, como fazemos com o Codex app, para que você tenha controle total sobre

10:02 quais são, de fato, os recursos da versão com a qual você espera desenvolver. Quanto aos protocolos, você pode iniciar o servidor de aplicativo tanto usando a entrada e saída padrão, ou STDIO, quanto usando web sockets. Isso depende do seu caso de uso e, sinceramente, a maneira mais fácil de descobrir o que funciona melhor para você provavelmente é simplesmente perguntar ao Codex. A partir daí, há duas maneiras de integrá-lo com mais facilidade. A primeira é o SDK de Python, que lançamos recentemente.

10:34 Ele cuida de boa parte do gerenciamento do ciclo de vida para você, então você não precisa se preocupar com nada disso. Além disso, facilita um pouco a integração de coisas como entrar com o ChatGPT e oferece uma interface familiar. Dito isso, estamos em uma conferência de engenharia de IA, então provavelmente a maioria de vocês vai escolher a opção dois: simplesmente perguntar ao Codex. Como era de se esperar, o Codex é muito bom em implementar esse protocolo, e, em geral, basta apontá-lo para a documentação. Na maioria dos casos, você nem precisa fazer isso, mas

11:05 às vezes ajuda dar essa indicação. A partir daí, você pode combiná-lo com qualquer um dos nossos plugins, como o de criar apps para macOS, se quiser iniciar algo rapidamente ou explorar possibilidades sem limites. Por exemplo, usei-o para criar um cliente em Visual Basic, para ter um app verdadeiramente nativo do Windows, e ele fez quase tudo de uma vez. Então, dá para criar aplicativos realmente impressionantes com isso em pouco tempo, sem precisar aprender todos os detalhes minuciosos da criação de um agent.

11:36 O mais interessante para mim nesse servidor de aplicativo, porém, é que você não está limitado à interface clássica de conversa com um agent. Você pode ser muito criativo: seja na maneira de acioná-lo dentro da interface do usuário e do seu app existente, seja executando-o em segundo plano, colocando-o em um hardware estranho, como Maddie faz o tempo todo, ou, se você é como eu, pensando: como posso enfiar isso em videogames? Recentemente, acho que há mais ou menos um mês, eu

12:08 pensei em como poderia executar o Codex dentro do Doom, em vez de executar o Doom dentro do Codex. Pensei em fazer isso ao vivo e vou dispensar algumas mensagens aqui. Tenho esta versão do Codex app para Doom e a abri na janela errada, então vou movê-la para cá. Pronto. Isso bagunçou os controles,

12:38 foi mal. Um instante. Às vezes, algo nessa configuração de dois monitores interfere na captura dos controles, então vamos torcer para que agora funcione melhor. Sim. Certo, este é um app Electron que usa a renderização Doom Wasm da Cloudflare. A maior parte do próprio mecanismo do jogo é implementada em C, e ele carrega o jogo FreeDoom, só que

13:09 eu manipulei o arquivo do jogo, fazendo o Codex alterá-lo. Então, como podem ver, isso é renderizado nativamente dentro do videogame usando o próprio mecanismo do jogo. Se interagirmos com ele aqui, vamos iniciar o Codex; e, mais uma vez, ele é renderizado nativamente dentro do próprio videogame e, em seguida, enviado ao servidor de aplicativo usando o protocolo IPC do Electron. Então, se dissermos “olá” aqui, podemos ver o Codex respondendo. Isso está usando o 5.5. A parte divertida

13:41 é que você pode usar ferramentas dinâmicas para expor funcionalidades adicionais. Então, naturalmente, podemos obter toda a armadura e a vida, e a chamada às ferramentas me mostra tudo isso; ou até pedir todas as armas com a munição completa. Ele chama todas as ferramentas diferentes. E está interagindo com elas, mas, de novo, lembrem-se de que ainda é um app

14:12 server rodando na minha máquina. Então, se eu perguntar “qual é o diretório?”, ele chama o Z shell e obtém o diretório de trabalho atual. E vocês podem ver aqui que ele está renderizando: ele tem seu próprio espaço de trabalho. Se quiser, você pode escrever código diretamente no Codex dentro do Doom. Não sei se recomendaria isso. Acho que o Codex app é um pouco melhor para isso. Mas dá para se divertir bastante e implementar sua própria interface.

14:42 Ótimo. Já conversei com alguns de vocês durante o evento sobre o servidor de aplicativo, e uma pergunta que surgiu várias vezes foi: qual é a diferença em relação ao Codex Exec? Se você já usou o Codex CLI, talvez conheça esse recurso. Existe outro comando chamado Codex Exec, que inicia uma interface não interativa para você enviar tarefas ao Codex. Isso é ótimo para scripts. Se estiver criando uma implementação de CI/CD e quiser automatizar certas ações, como a correção auto

15:13 mática de um PR, essa é uma ótima opção. Mas, se estiver tentando criar um cliente mais abrangente, com o qual você interage e no qual exibe o agent — ou, mais importante, se estiver tentando fazer algo como iniciar várias threads do Codex ao mesmo tempo, por exemplo, executar seu próprio harness de evals ou usar /goal —, é aí que o servidor de aplicativo realmente se destaca, porque você tem controle total sobre o harness e não

15:44 precisa descobrir por conta própria como paralelizar todas as chamadas do Codex Exec. Em vez disso, basta enviar vários eventos de novas threads e iniciar as tarefas dessa maneira. Antes de liberar vocês para a palestra principal, tenho mais três dicas para recapitular o que conversamos e lembrar o que considerar ao usar o servidor de aplicativo. A primeira é que você deve distribuir sua própria versão do harness. Isso vai evitar muitas dores de cabeça. Se você depender do

16:14 CLI instalado pelo usuário, vai se deparar constantemente com coisas como alterações incompatíveis — embora tentemos minimizá-las —, principalmente se depender de funcionalidades experimentais. Mas você também não precisará se preocupar se o usuário atualizou a versão e tem a funcionalidade mais recente que você quer usar, nem terá que pedir que ele a atualize. Portanto, distribua sua própria versão do harness. A outra coisa é que você deve, sem dúvida, expor novas funções na sua interface. Por exemplo, fazemos isso no Codex app,

16:45 para que ele consiga se controlar como parte da thread do Codex, por exemplo, iniciando automações etc. Mas marque-as como adiadas. Assim, você não polui desnecessariamente a context window com todas as diferentes funções adicionais que está adicionando e, em vez disso, ainda as deixa disponíveis para o agent sem necessariamente confundi-lo. E, se estiver mudando as instruções, tente começar, por exemplo, adicionando instruções de desenvolvedor, em vez de mudar as instruções básicas. Talvez você sinta que

17:16 quer partir logo para “vou escrever meu próprio system prompt”, mas há muitas coisas diferentes em que precisamos pensar constantemente ao criar um harness, para garantir que o prompt real esteja na distribuição e que o agent tenha um bom desempenho. E você perde tudo isso se simplesmente começa a escrever seu próprio system prompt. Então, tome cuidado se for fazer isso. Com isso, muito obrigado. Obrigado por dedicarem seu tempo. Fiquem à vontade para escanear o código QR se quiserem os slides. Vou ficar por aqui pelos próximos 15 minutos

17:46 no estande da Open AI, caso queiram me fazer alguma pergunta. Muito obrigado. >> [música]

Transcrição original

[00:12] 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

[00:43] 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

[01:15] 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

[01:45] 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.

[02:17] 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.

[02:47] 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

[03:19] 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

[03:50] 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

[04:22] 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

[04:53] 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,

[05:23] 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

[05:54] 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

[06:25] 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

[06:56] 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

[07:27] 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

[07:59] 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,

[08:30] 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

[09:01] 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

[09:31] 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

[10:02] 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.

[10:34] 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

[11:05] 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.

[11:36] 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

[12:08] 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,

[12:38] 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

[13:09] 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

[13:41] 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

[14:12] 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.

[14:42] 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

[15:13] 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

[15:44] 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

[16:14] 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,

[16:45] 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

[17:16] 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

[17:46] at the Open AI booth if you want to ask me any questions there. Thank you so much. >> [music]