## Why
`TurnHandle.run()` returned the raw app-server `Turn`, whose live
start/completed payloads do not include loaded `items`, so users saw
empty `items` after starting a turn. That made the handle-based path
behave differently from `Thread.run(...)`, and pushed examples toward
persisted-thread reads plus helper extraction.
This PR makes the run APIs standalone: starting a turn and running it
returns collected turn data directly, or fails visibly when required
stream events are missing.
## What Changed
- Replaces the public `RunResult` export with `TurnResult`.
- Adds turn metadata to `TurnResult`: `id`, `status`, `error`,
`started_at`, `completed_at`, and `duration_ms`, alongside
`final_response`, `items`, and `usage`.
- Changes `TurnHandle.run()` and `AsyncTurnHandle.run()` to consume
stream events with the same collector used by `Thread.run(...)`.
- Exports `TurnError` from `openai_codex.types` for the new result
shape.
- Updates tests, examples, docs, and the walkthrough notebook to use
`result.final_response` and `result.items` directly.
- Removes persisted-thread helper paths and placeholder/skipped control
flows from the public examples and notebook.
## Verification
- `python3 -m py_compile ...` over changed SDK, example, and test Python
files.
- `python3 -c "import json;
json.load(open('sdk/python/notebooks/sdk_walkthrough.ipynb'))"`
- `git diff --check`
- `PYTHONPATH=sdk/python/src python3 -c ...` import/signature smoke for
`TurnResult`, `TurnHandle.run`, and `AsyncTurnHandle.run`.
3.3 KiB
FAQ
Thread vs turn
- A
Threadis conversation state. - A
Turnis one model execution inside that thread. - Multi-turn chat means multiple turns on the same
Thread.
run() vs stream()
Thread.run(...)starts a turn and returnsTurnResult.TurnHandle.run()/AsyncTurnHandle.run()consumes events for an existing turn handle and returns the sameTurnResultshape.TurnHandle.stream()/AsyncTurnHandle.stream()yields raw notifications (Notification) so you can react event-by-event.
Choose run() for most apps. Choose stream() for progress UIs, custom timeout logic, or custom parsing.
Sync vs async clients
Codexis the sync public API.AsyncCodexis an async replica of the same public API shape.- Prefer
async with AsyncCodex()for async code. It is the standard path for explicit startup/shutdown, andAsyncCodexinitializes lazily on context entry or first awaited API use.
If your app is not already async, stay with Codex.
How do I log in?
login_api_key(...)authenticates immediately with an API key.login_chatgpt()starts browser login and returns a handle withauth_url.login_chatgpt_device_code()starts device-code login and returns a handle withverification_urlanduser_code.- Interactive handles expose
wait()for the matchingaccount/login/completednotification andcancel()to stop that attempt. account()reads the current account state, andlogout()clears it.
Public kwargs are snake_case
Public API keyword names are snake_case. The SDK still maps them to wire camelCase under the hood.
If you are migrating older code, update these names:
approvalPolicy->approval_policybaseInstructions->base_instructionsdeveloperInstructions->developer_instructionsmodelProvider->model_providermodelProviders->model_providerssortKey->sort_keysourceKinds->source_kindsoutputSchema->output_schemasandboxPolicy->sandbox_policy
Why only thread_start(...) and thread_resume(...)?
The public API keeps only explicit lifecycle calls:
thread_start(...)to create new threadsthread_resume(thread_id, ...)to continue existing threads
This avoids duplicate ways to do the same operation and keeps behavior explicit.
Why does constructor fail?
Codex() is eager: it starts transport and calls initialize in __init__.
Common causes:
- published runtime package (
openai-codex-cli-bin) is not installed - local
codex_binoverride points to a missing file - app-server version older than the SDK schema
Why does a turn "hang"?
A turn is complete only when turn/completed arrives for that turn ID.
run()waits for this automatically.- With
stream(), keep consuming notifications until completion.
How do I retry safely?
Use retry_on_overload(...) for transient overload failures (ServerBusyError).
Do not blindly retry all errors. For InvalidParamsError or MethodNotFoundError, fix inputs or update the runtime/schema version instead.
Common pitfalls
- Starting a new thread for every prompt when you wanted continuity.
- Forgetting to
close()(or not using context managers). - Reading
Turn.itemsfrom live start/completed payloads instead of usingTurnResult.items. - Mixing SDK input classes with raw dicts incorrectly.