mirror of
https://github.com/openai/codex.git
synced 2026-05-03 19:06:58 +00:00
## Summary This PR hardens package-manager usage across the repo to reduce dependency supply-chain risk. It also removes the stale `codex-cli` Docker path, which was already broken on `main`, instead of keeping a bitrotted container workflow alive. ## What changed - Updated pnpm package manager pins and workspace install settings. - Removed stale `codex-cli` Docker assets instead of trying to keep a broken local container path alive. - Added uv settings and lockfiles for the Python SDK packages. - Updated Python SDK setup docs to use `uv sync`. ## Why This is primarily a security hardening change. It reduces package-install and supply-chain risk by ensuring dependency installs go through pinned package managers, committed lockfiles, release-age settings, and reviewed build-script controls. For `codex-cli`, the right follow-up was to remove the local Docker path rather than keep patching it: - `codex-cli/Dockerfile` installed `codex.tgz` with `npm install -g`, which bypassed the repo lockfile and age-gated pnpm settings. - The local `codex-cli/scripts/build_container.sh` helper was already broken on `main`: it called `pnpm run build`, but `codex-cli/package.json` does not define a `build` script. - The container path itself had bitrotted enough that keeping it would require extra packaging-specific behavior that was not otherwise needed by the repo. ## Gaps addressed - Global npm installs bypassed the repo lockfile in Docker and CLI reinstall paths, including `codex-cli/Dockerfile` and `codex-cli/bin/codex.js`. - CI and Docker pnpm installs used `--frozen-lockfile`, but the repo was missing stricter pnpm workspace settings for dependency build scripts. - Python SDK projects had `pyproject.toml` metadata but no committed `uv.lock` coverage or uv age/index settings in `sdk/python` and `sdk/python-runtime`. - The secure devcontainer install path used npm/global install behavior without a local locked package-manager boundary. - The local `codex-cli` Docker helper was already broken on `main`, so this PR removes that stale Docker path instead of preserving a broken surface. - pnpm was already pinned, but not to the current repo-wide pnpm version target. ## Verification - `pnpm install --frozen-lockfile` - `.devcontainer/codex-install`: `pnpm install --prod --frozen-lockfile` - `.devcontainer/codex-install`: `./node_modules/.bin/codex --version` - `sdk/python`: `uv lock --check`, `uv sync --locked --all-extras --dry-run`, `uv build` - `sdk/python-runtime`: `uv lock --check`, `uv sync --locked --dry-run`, `uv build --wheel` - `pnpm -r --filter ./sdk/typescript run build` - `pnpm -r --filter ./sdk/typescript run lint` - `pnpm -r --filter ./sdk/typescript run test` - `node --check codex-cli/bin/codex.js` - `docker build -f .devcontainer/Dockerfile.secure -t codex-secure-test .` - `cargo build -p codex-cli` - repo-wide package-manager audit
3.2 KiB
3.2 KiB
Getting Started
This is the fastest path from install to a multi-turn thread using the public SDK surface.
The SDK is experimental. Treat the API, bundled runtime strategy, and packaging details as unstable until the first public release.
1) Install
From repo root:
cd sdk/python
uv sync
source .venv/bin/activate
Requirements:
- Python
>=3.10 - uv
- installed
openai-codex-cli-binruntime package, or an explicitcodex_binoverride - local Codex auth/session configured
2) Run your first turn (sync)
from codex_app_server import Codex
with Codex() as codex:
server = codex.metadata.serverInfo
print("Server:", None if server is None else server.name, None if server is None else server.version)
thread = codex.thread_start(model="gpt-5.4", config={"model_reasoning_effort": "high"})
result = thread.run("Say hello in one sentence.")
print("Thread:", thread.id)
print("Text:", result.final_response)
print("Items:", len(result.items))
What happened:
Codex()started and initializedcodex app-server.thread_start(...)created a thread.thread.run("...")started a turn, consumed events until completion, and returned the final assistant response plus collected items and usage.result.final_responseisNonewhen no final-answer or phase-less assistant message item completes for the turn.- use
thread.turn(...)when you need aTurnHandlefor streaming, steering, interrupting, or turn IDs/status - one client can have only one active turn consumer (
thread.run(...),TurnHandle.stream(), orTurnHandle.run()) at a time in the current experimental build
3) Continue the same thread (multi-turn)
from codex_app_server import Codex
with Codex() as codex:
thread = codex.thread_start(model="gpt-5.4", config={"model_reasoning_effort": "high"})
first = thread.run("Summarize Rust ownership in 2 bullets.")
second = thread.run("Now explain it to a Python developer.")
print("first:", first.final_response)
print("second:", second.final_response)
4) Async parity
Use async with AsyncCodex() as the normal async entrypoint. AsyncCodex
initializes lazily, and context entry makes startup/shutdown explicit.
import asyncio
from codex_app_server import AsyncCodex
async def main() -> None:
async with AsyncCodex() as codex:
thread = await codex.thread_start(model="gpt-5.4", config={"model_reasoning_effort": "high"})
result = await thread.run("Continue where we left off.")
print(result.final_response)
asyncio.run(main())
5) Resume an existing thread
from codex_app_server import Codex
THREAD_ID = "thr_123" # replace with a real id
with Codex() as codex:
thread = codex.thread_resume(THREAD_ID)
result = thread.run("Continue where we left off.")
print(result.final_response)
6) Generated models
The convenience wrappers live at the package root, but the canonical app-server models live under:
from codex_app_server.generated.v2_all import Turn, TurnStatus, ThreadReadResponse
7) Next stops
- API surface and signatures:
docs/api-reference.md - Common decisions/pitfalls:
docs/faq.md - End-to-end runnable examples:
examples/README.md