Commit Graph

12 Commits

  • [2/8] Generate Python SDK types from pinned runtime (#21893)
    ## Why
    
    Once the SDK declares its runtime package, generated Python artifacts
    should come from that pinned runtime rather than whatever app-server
    schema happens to be in the current checkout. That keeps the generated
    API and model surface aligned with the runtime users install.
    
    ## What
    
    - Teach `scripts/update_sdk_artifacts.py generate-types` to invoke the
    pinned runtime package for schema generation.
    - Regenerate `v2_all.py`, `notification_registry.py`, and generated
    public wrapper methods from that schema.
    - Add freshness coverage so regenerating from the pinned runtime must
    leave checked-in artifacts unchanged.
    
    ## Stack
    
    1. #21891 `[1/8]` Pin Python SDK runtime dependency
    2. This PR `[2/8]` Generate Python SDK types from pinned runtime
    3. #21895 `[3/8]` Run Python SDK tests in CI
    4. #21896 `[4/8]` Define Python SDK public API surface
    5. #21905 `[5/8]` Rename Python SDK package to `openai-codex`
    6. #21910 `[6/8]` Add high-level Python SDK approval mode
    7. #22014 `[7/8]` Add Python SDK app-server integration harness
    8. #22021 `[8/8]` Add Python SDK Ruff formatting
    
    ## Verification
    
    - Added `test_generated_files_are_up_to_date` for pinned-runtime
    generation drift.
    - Added generator-structure tests for schema annotation and notification
    metadata generation.
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • Add remote plugin skill read API (#20150)
    ## Summary
    
    Adds an app-server `plugin/skill/read` method for remote plugin skill
    markdown. The new method calls the plugin-service skill detail endpoint
    and returns `skill_md_contents`, so clients can preview skills for
    remote plugins before the bundle is installed locally.
    
    ## Why
    
    Uninstalled remote plugin skills do not have local `SKILL.md` files.
    Without an on-demand remote read, the desktop plugin details UI cannot
    render the skill details modal for those skills.
    
    ## Validation
    
    - `just write-app-server-schema`
    - `just fmt`
    - `cargo test -p codex-app-server-protocol`
    - `cargo test -p codex-app-server --test all --
    suite::v2::plugin_read::plugin_skill_read_reads_remote_skill_contents_when_remote_plugin_enabled
    --exact`
    - `just fix -p codex-app-server-protocol -p codex-core-plugins -p
    codex-app-server`
  • Publish Python SDK with Codex-pinned versioning (#18996)
    **note**: a large chunk of this diff comes from regenerating Python
    types after app-server schema changes on `main`.
    
    This is PR 3 of 3 for the Python SDK PyPI publishing split. PR #18862
    refreshed the generated SDK surface, and PR #18865 made the runtime
    package publishable as `openai-codex-cli-bin`; this final PR makes the
    SDK package publishable as `openai-codex-app-server-sdk` and pins both
    packages to the same Codex runtime version.
    
    The key idea is that the published SDK version is the Codex runtime
    version. That one version now drives the SDK package version, the exact
    runtime dependency, the client version reported by the SDK, and the
    bootstrap runtime pin. This keeps release-time versioning in one lane
    instead of scattering checked-in literals through the package.
    
    ## What changed
    
    - Rename the SDK distribution from `codex-app-server-sdk` to
    `openai-codex-app-server-sdk` for conflict-free PyPI publishing.
    - Use `stage-sdk --codex-version ...` with one Codex version for both
    the SDK package version and exact `openai-codex-cli-bin` dependency.
    - Preserve hidden legacy `--runtime-version` / `--sdk-version` args only
    to reject mismatched versions during staging.
    - Map PEP 440 package versions back to Codex release tags for runtime
    setup downloads, e.g. `0.116.0a1` -> `rust-v0.116.0-alpha.1`.
    - Derive `codex_app_server.__version__`, the default
    `AppServerConfig.client_version`, and
    `_runtime_setup.pinned_runtime_version()` from the SDK package/project
    version instead of hardcoding duplicate version strings.
    - Carry the current generated SDK refresh from `main` so
    `generate-types` stays clean after recent app-server schema changes.
    - Update `sdk/python/uv.lock` for the renamed editable package.
    
    ## Validation
    
    - `uv run --extra dev pytest` in `sdk/python` -> 59 passed, 37 skipped.
    - Targeted `uv run ruff check` for the touched SDK files.
    - `git diff --check`.
    - Staged runtime with `--codex-version rust-v0.116.0-alpha.1
    --platform-tag macosx_11_0_arm64`.
    - Staged SDK with `--codex-version rust-v0.116.0-alpha.1`.
    - Built runtime wheel, SDK wheel, and SDK sdist.
    - `twine check /tmp/codex-python-pr3-build/dist/*` -> passed.
    - Clean venv smoke installed `openai-codex-app-server-sdk==0.116.0a1`
    from local dist and pulled `openai-codex-cli-bin==0.116.0a1`.
    - Smoke imports passed for `Codex` and `bundled_codex_path()`.
  • Fix auto-review config compatibility across protocol and SDK (#19113)
    ## Why
    
    This keeps the partial Guardian subagent -> Auto-review rename
    forward-compatible across mixed Codex installations. Newer binaries need
    to understand the new `auto_review` spelling, but they cannot write it
    to shared `~/.codex/config.toml` yet because older CLI/app-server
    bundles only know `user` and `guardian_subagent` and can fail during
    config load before recovering.
    
    The Python SDK had the opposite compatibility gap: app-server responses
    can contain `approvalsReviewer: "auto_review"`, but the checked-in
    generated SDK enum did not accept that value.
    
    ## What Changed
    
    - Keep `ApprovalsReviewer::AutoReview` readable from both
    `guardian_subagent` and `auto_review`, while serializing it as
    `guardian_subagent` in both protocol crates.
    - Update TUI Auto-review persistence tests so enabling Auto-review
    writes `approvals_reviewer = "guardian_subagent"` while UI copy still
    says Auto-review.
    - Map managed/cloud `feature_requirements.auto_review` to the existing
    `Feature::GuardianApproval` gate without adding a broad local
    `[features].auto_review` key or changing config writes.
    - Add `auto_review` to the Python SDK `ApprovalsReviewer` enum and cover
    `ThreadResumeResponse` validation.
    
    ## Testing
    
    - `cargo test -p codex-protocol approvals_reviewer`
    - `cargo test -p codex-app-server-protocol approvals_reviewer`
    - `cargo test -p codex-tui
    update_feature_flags_enabling_guardian_selects_auto_review`
    - `cargo test -p codex-tui
    update_feature_flags_enabling_guardian_in_profile_sets_profile_auto_review_policy`
    - `cargo test -p codex-core
    feature_requirements_auto_review_disables_guardian_approval`
    - `pytest
    sdk/python/tests/test_client_rpc_methods.py::test_thread_resume_response_accepts_auto_review_reviewer`
    - `git diff --check`
  • Refresh generated Python app-server SDK types (#18862)
    This is the first step in splitting the Python SDK PyPI publish work
    into reviewable layers: land the generated SDK refresh by itself before
    changing packaging mechanics. The next PRs will make the runtime wheel
    publishable, then wire the SDK package/version pinning to that runtime.
    
    ## Summary
    - Refresh generated Python app-server v2 models and notification
    registry from the current schema.
    - Update the public API signature expectations for the newly generated
    kwargs.
    
    ## Stack
    - PR 1 of 3 for the Python SDK PyPI publishing split.
    - Follow-up PRs will handle runtime wheel publishing mechanics, then
    SDK/package version pinning.
    
    ## Tests
    - `uv run --extra dev pytest` in `sdk/python` -> 51 passed, 37 skipped.
  • Add usage-based business plan types (#15934)
    ## Summary
    - add `self_serve_business_usage_based` and `enterprise_cbp_usage_based`
    to the public/internal plan enums and regenerate the app-server + Python
    SDK artifacts
    - map both plans through JWT login and backend rate-limit payloads, then
    bucket them with the existing Team/Business entitlement behavior in
    cloud requirements, usage-limit copy, tooltips, and status display
    - keep the earlier display-label remap commit on this branch so the new
    Team-like and Business-like plans render consistently in the UI
    
    ## Testing
    - `just write-app-server-schema`
    - `uv run --project sdk/python python
    sdk/python/scripts/update_sdk_artifacts.py generate-types`
    - `just fix -p codex-protocol -p codex-login -p codex-core -p
    codex-backend-client -p codex-cloud-requirements -p codex-tui -p
    codex-tui-app-server -p codex-backend-openapi-models`
    - `just fmt`
    - `just argument-comment-lint`
    - `cargo test -p codex-protocol
    usage_based_plan_types_use_expected_wire_names`
    - `cargo test -p codex-login usage_based`
    - `cargo test -p codex-backend-client usage_based`
    - `cargo test -p codex-cloud-requirements usage_based`
    - `cargo test -p codex-core usage_limit_reached_error_formats_`
    - `cargo test -p codex-tui plan_type_display_name_remaps_display_labels`
    - `cargo test -p codex-tui remapped`
    - `cargo test -p codex-tui-app-server
    plan_type_display_name_remaps_display_labels`
    - `cargo test -p codex-tui-app-server remapped`
    - `cargo test -p codex-tui-app-server
    preserves_usage_based_plan_type_wire_name`
    
    ## Notes
    - a broader multi-crate `cargo test` run still hits unrelated existing
    guardian-approval config failures in
    `codex-rs/core/src/config/config_tests.rs`
  • Revert "fix: harden plugin feature gating" (#15102)
    Reverts openai/codex#15020
    
    I messed up the commit in my PR and accidentally merged changes that
    were still under review.
  • fix: harden plugin feature gating (#15020)
    1. Use requirement-resolved config.features as the plugin gate.
    2. Guard plugin/list, plugin/read, and related flows behind that gate.
    3. Skip bad marketplace.json files instead of failing the whole list.
    4. Simplify plugin state and caching.
  • Cleanup skills/remote/xxx endpoints. (#14977)
    Remote skills/remote/xxx as they are not in used for now.
  • feat: support remote_sync for plugin install/uninstall. (#14878)
    - Added forceRemoteSync to plugin/install and plugin/uninstall.
    - With forceRemoteSync=true, we update the remote plugin status first,
    then apply the local change only if the backend call succeeds.
    - Kept plugin/list(forceRemoteSync=true) as the main recon path, and for
    now it treats remote enabled=false as uninstall. We
    will eventually migrate to plugin/installed for more precise state
    handling.
  • Refresh Python SDK generated types (#14646)
    ## Summary
    - regenerate `sdk/python` protocol-derived artifacts on latest
    `origin/main`
    - update `notification_registry.py` to match the regenerated
    notification set
    - fix the stale SDK test expectation for `GranularAskForApproval`
    
    ## Validation
    - `cd sdk/python && python scripts/update_sdk_artifacts.py
    generate-types`
    - `cd sdk/python && python -m pytest`
  • Add Python app-server SDK (#14435)
    ## TL;DR
    Bring the Python app-server SDK from `main-with-prs-13953-and-14232`
    onto current `main` as a standalone SDK-only PR.
    
    - adds the new `sdk/python` and `sdk/python-runtime` package trees
    - keeps the scope to the SDK payload only, without the unrelated
    branch-history or workflow changes from the source branch
    - regenerates `sdk/python/src/codex_app_server/generated/v2_all.py`
    against current `main` schema so the extracted SDK matches today's
    protocol definitions
    
    ## Validation
    - `PYTHONPATH=sdk/python/src python3 -m pytest sdk/python/tests`
    
    Co-authored-by: Codex <noreply@openai.com>