c0e1b78253
## Why Existing login-keychain access rules identify the CLI as `codex`. Packaging it in an app bundle must preserve that code-signing identifier independently of the bundle identifier and provisioned App ID. ## What changed - Sign the provisioned CLI with the identifier `codex`, retaining `com.openai.codex.cli` as its bundle identifier. - Require the expected signing identifier and team during signature verification, and reject unexpected bundle identifiers, executable names, or package types. - Document the identity distinction and keychain compatibility limits. ## Testing Extend signing-driver tests to check the signing identifier, verification requirement, bundle metadata, and provisioned entitlements, and to reject altered bundle identity fields. These tests use generated credentials and stubbed native tools; they do not verify runtime keychain access or credential recovery. GitOrigin-RevId: ab00072e48189551adb0e70008210fee6d36241d
2.2 KiB
Provisioned CLI signing identity
The provisioned CLI has two deliberately separate identifiers:
| Purpose | Identifier |
|---|---|
| Code-signing identifier | codex |
| Bundle identifier | com.openai.codex.cli |
| Provisioned App ID and keychain group | <TeamID>.com.openai.codex.cli |
The code-signing identifier preserves access to existing login-keychain items whose access rules require the original CLI identity. Giving the CLI an app bundle must not change that identifier. The bundle identifier, App ID, entitlements, profile, and approved certificate remain independently validated. The native-verification keys use the provisioned keychain group; they do not replace existing login-keychain credential access rules.
Changing the new binary's designated requirement to accept both identifiers
would not make it satisfy an existing item's requirement for codex. Items
created by a binary signed as com.openai.codex.cli are a separate compatibility
case: restoring codex does not silently authorize access to those items.
The signing backend must honor an explicit --binary-identifier when signing
an app bundle. The wrapper signs the bundle once; rcodesign seals its metadata
and resources while retaining codex as the main executable's identity.
Release tool artifact URIs and SHA-256 digests are pinned in the signing
environment configuration.
Release verification
When CODEX_PROVISIONED_MACOS_CANDIDATE is enabled, tag releases automatically
publish the provisioned archives and versioned codex-provisioned manifest after
both architecture packages pass the existing signature, entitlement, profile,
architecture, stapling, Gatekeeper, and package-smoke checks. An enabled
provisioned build that fails verification blocks release publication.
The signing-driver tests use generated credentials and stubbed native tools. They cover the signing command contract and failure handling. Actual keychain access and credential recovery across identity changes require runtime testing; these unit tests do not establish that behavior.