The official Codex SDKs give a programmatic interface for running tasks from TypeScript/JavaScript and Python. They are needed where the codex exec shell commands are no longer enough: when you must hold a thread, continue the conversation across several turns and embed the final result into a service. If exec is the agent as a link of a pipeline, the SDK is the agent as an embedded library controlled by your code: it creates a thread, leads it and consumes the result programmatically.

The key concepts of the SDK are the thread and the turn. A thread is a conversation that lives between calls; a turn is one step within it. This model is needed precisely for multi-step work: you start a task, get the result, continue the same thread with the next request, preserving context. A one-off exec does not give this - it finishes and forgets; the SDK, on the contrary, lets you build a service where the agent leads coherent work across several calls, like a real dialogue.

It helps to see the TypeScript integration in full once. Below are installing the package and minimal code: create a client, start a thread, run a request to inspect the repository without edits. The result comes into the code as a value that can be parsed and used further. This is the point of the SDK: the agent is embedded in your process, and you work with its output as with an ordinary result of an async call rather than parsing text from stdout.

The Python integration is arranged symmetrically but with an explicit sandbox model. Below are installing the package and code via a context manager: create a client, start a thread with sandbox=Sandbox.read_only, run. Note read_only right in the thread start - it is the same boundary discipline as in the CLI but expressed in code. The SDK does not cancel the sandbox and permissions: they are set programmatically, and setting them narrowly here is as important as in interactive work.

Boundaries in the SDK are set explicitly, because there is no one to confirm on the fly. As in exec, a programmatic run is non-interactive: the sandbox, permissions and approval mode are defined in code before the run, not along the way. Read-only for an exploratory task, narrow access for an editing one - this is expressed by the thread-start parameters. The temptation to "give the SDK full access so it does not get in the way" is as dangerous here as disabling the sandbox in the CLI: a programmatic interface does not remove responsibility for boundaries.