fix(runtime): preserve Codex OAuth env isolation

[tuzer69]

Summary

• Prevent Codex SDK/local transports from accidentally inheriting generic OpenAI API env defaults (OPENAI_API_KEY, OPENAI_BASE_URL) when the user intends to run through codex login / ChatGPT OAuth.
• Keep direct OpenAI-compatible API usage available for the api transport and for explicitly configured SDK profiles via apiKeyEnvVar, while preserving explicit baseUrl / CODEX_BASE_URL overrides.
• Add regression coverage for both runtime profile resolution and the Codex SDK constructor environment so placeholder keys like OPENAI_API_KEY=sk-000 cannot hijack OAuth-backed chat again.
• Ignore generated local project/perf directories so repository checks do not format app-created workspaces under the default PROJECTS_DIR.

Problem

A Codex runtime profile using transport: sdk is expected to use the local Codex login state (codex login, e.g. ChatGPT OAuth). However, the SDK adapter currently forwards all OPENAI_* environment variables and also infers apiKey / baseUrl from OPENAI_API_KEY and OPENAI_BASE_URL by default.

That means a normal local/Docker setup can be logged in successfully with codex login status, but chat still fails if .env contains a placeholder or unrelated OpenAI API config such as:

• OPENAI_API_KEY=sk-000
• OPENAI_BASE_URL=http://host.docker.internal:8317/v1

In that case Codex SDK is instantiated as an API-key client and sends requests to /v1/responses, producing errors like 401 Incorrect API key provided or stream disconnected before completion, instead of using the OAuth-backed Codex session.

Fix

For local Codex transports (sdk, cli, app-server), runtime resolution no longer treats OPENAI_API_KEY / OPENAI_BASE_URL as implicit defaults. The SDK child environment also blocks OPENAI_API_KEY and OPENAI_BASE_URL unless API-key auth is explicitly requested through profile options.

The api transport is unchanged: it still requires API key + base URL. Explicit SDK overrides are also preserved, so users who really want API-key-backed SDK runs can set apiKeyEnvVar or apiKey, and users can still opt into a custom Codex endpoint via profile baseUrl or CODEX_BASE_URL.

Test plan

• npm run format:check
• npm run lint --workspace=@aif/runtime
• npm test -- --run src/__tests__/resolution.test.ts src/__tests__/codexSdk.test.ts from packages/runtime
• npm test --workspace=@aif/runtime (59 files, 786 tests)
• npm run build --workspace=@aif/runtime
• npm run ai:validate attempted; on this Windows machine it reaches the perf phase and then fails in the existing web perf harness with spawn EINVAL from packages/web/scripts/run-perf.mjs, unrelated to the runtime changes.

[lee-to]

/code-review

[lee-to]

Code review

This PR narrows Codex OAuth/API-key separation for SDK profile resolution and adds focused regression tests. The direction is right, but the fix is incomplete for the local Codex transports called out in the PR body: SDK is isolated, while CLI/App Server can still inherit the ambient OPENAI_API_KEY that this change is trying to prevent from hijacking OAuth-backed runs.

Must fix

1. Local Codex transports still inherit ambient OpenAI API keys — packages/runtime/src/adapters/codex/cli.ts:267 and packages/runtime/src/adapters/codex/appServer/process.ts:118 — resolveRuntimeProfile() now returns apiKeyEnvVar: null for local Codex transports unless the profile explicitly opts in, but both local process builders independently fall back to OPENAI_API_KEY. CLI forwards all OPENAI_ keys through the allowlist, and App Server defaults apiKeyEnvVar to OPENAI_API_KEY, then reads process.env[apiKeyEnvVar] / process.env.OPENAI_API_KEY and writes it into the child env. That means OPENAI_API_KEY=sk-000 can still hijack transport: "cli" or transport: "app-server", despite the PR claiming local transports are protected. Make CLI/App Server mirror the SDK behavior: only forward/use OPENAI_API_KEY when apiKeyEnvVar or apiKey is explicitly configured, and add regression tests for both transports.

Should fix

1. Docs still describe the old Codex auth behavior — docs/configuration.md:90, docs/configuration.md:91, .env.example:128 — the runtime behavior is changing so local Codex SDK/CLI/App Server profiles prefer codex login and no longer implicitly consume OPENAI_API_KEY / OPENAI_BASE_URL; API transport keeps the OpenAI-compatible API env behavior. Update the configuration docs and env example so users know to set profile apiKeyEnvVar/apiKey for explicit API-key-backed local runs, and to use CODEX_BASE_URL or profile baseUrl where that is the supported local override.

Nits

• None.

Context gates

• Architecture: pass — the change stays within @aif/runtime and does not violate package dependency boundaries.
• Rules: error — the runtime checklist says adapter fixes must audit equivalent adapter paths; the SDK path was fixed, but CLI/App Server local transport env handling was left behind.
• Roadmap: warn — this is a fix PR and does not reference a roadmap milestone; no direct contradiction found.
• CHECKLIST compliance (touched packages: packages/runtime): error — runtime checklist parity item is not satisfied for Codex local transports.
• Docs sync: warn — runtime auth/default env behavior changed without matching docs/configuration.md / .env.example updates.
• PR size (154 lines / 6 files / 1 concern): pass — comfortably below the decomposition threshold.
• Risk gating (feature flag): n/a — this is a targeted auth-isolation bug fix with explicit opt-in preserved for API-key local runs.

Verdict: REQUEST_CHANGES until CLI/App Server stop implicitly consuming OPENAI_API_KEY in the same way SDK now does.

[ichinya]

Code review

This PR aims to keep local Codex OAuth / codex login flows from being hijacked by ambient OpenAI-compatible API env defaults. The SDK and profile-resolution direction is right, and the new SDK tests cover the reported failure mode for transport: "sdk".

Current head: e549b76. This is still not safe to merge as-is: the earlier blocker for non-SDK local Codex transports remains, and the branch is now 32 commits behind current main with overlapping runtime/docs/env changes.

Response pass

• Addressed: SDK profile resolution no longer treats ambient OPENAI_API_KEY / OPENAI_BASE_URL as implicit defaults for local Codex SDK profiles.
• Addressed: SDK constructor options now omit apiKey, baseUrl, env.OPENAI_API_KEY, and env.OPENAI_BASE_URL by default, while preserving explicit apiKeyEnvVar.
• Still unresolved: Codex CLI and App Server still independently inherit / inject ambient OPENAI_API_KEY, so the PR body’s “local Codex transports (sdk, cli, app-server)" claim is not true yet.
• Still unresolved: docs and .env.example still describe the old Codex auth/default env behavior.
• New blocker found: the branch is 32 commits behind current main; current main has overlapping runtime, Codex, docs/configuration, env/Turbo, and lockfile changes, so the existing green checks are stale.

What looks good

• The SDK path now blocks ambient OPENAI_API_KEY and OPENAI_BASE_URL unless API-key auth is explicitly requested.
• Explicit SDK API-key usage through apiKeyEnvVar remains supported and covered by regression tests.
• Runtime profile resolution now distinguishes Codex API transport from local Codex transports, and keeps CODEX_BASE_URL / explicit baseUrl as the local override path.
• The added ignore entries for generated project/perf directories are consistent with the stated local-checks problem.

Must fix

1. [P1] Local Codex CLI/App Server still consume ambient OpenAI API keys — packages/runtime/src/adapters/codex/cli.ts, packages/runtime/src/adapters/codex/appServer/process.ts

   The SDK fix does not cover the other local Codex transports named in the PR body.

   Broken scenario: a user has OPENAI_API_KEY=sk-000 in .env, is logged in through codex login, and runs a profile with transport: "cli" or transport: "app-server" without explicit API-key opt-in. resolveRuntimeProfile() now correctly resolves no apiKeyEnvVar, but both local process builders reconstruct child env from process.env instead of respecting that resolved null state.

   In the CLI adapter, the env allowlist still includes the OPENAI_ prefix and only blocks OPENAI_BASE_URL, so ambient OPENAI_API_KEY is still forwarded into the Codex CLI process. In App Server, the env allowlist also forwards OPENAI_, then buildCodexAppServerEnvWithStats() defaults apiKeyEnvVar to OPENAI_API_KEY, reads process.env[apiKeyEnvVar] / process.env.OPENAI_API_KEY, and writes the key back into the child env.

   This preserves the same hijack class that the PR fixes for SDK: local OAuth-backed runs can still be forced into API-key auth and fail with the placeholder/wrong key. It also violates the runtime package checklist’s adapter-parity rule for adapter fixes.

   Expected fix:

   • Make CLI and App Server mirror the SDK behavior: block ambient OPENAI_API_KEY by default, and only forward/use it when apiKeyEnvVar or apiKey is explicitly configured.

   • Remove the implicit App Server fallback to process.env.OPENAI_API_KEY when no explicit API-key opt-in exists.

   • Keep explicit apiKey, explicit apiKeyEnvVar, profile baseUrl, and CODEX_BASE_URL behavior intact.

   • Add regression tests for CLI and App Server env builders:

     • ambient OPENAI_API_KEY / OPENAI_BASE_URL are absent by default;
     • explicit apiKeyEnvVar: "OPENAI_API_KEY" forwards the key;
     • explicit apiKey is injected as documented;
     • CODEX_BASE_URL / explicit local base URL still work;
     • API transport behavior remains unchanged.

Must fix / merge-order requirement

1. [P1] Do not merge/deploy this PR before rebasing onto current main

   The PR head is 1 commit ahead but 32 commits behind current main. The current base has changed in areas that overlap this PR’s risk surface: runtime/Codex files, docs/configuration, .env.example, shared env parsing, Turbo env passthrough, package manifests, and lockfiles.

   The current GitHub checks are useful, but they only prove this head against the stale merge base. They do not prove the final merge result against current main.

   Acceptable options:

   • rebase onto current main;
   • resolve any runtime/docs/env/lockfile conflicts;
   • rerun Build, Lint, Tests, Security Audit, and MCP Unit on the rebased head;
   • rerun the focused Codex SDK/CLI/App Server env isolation tests after the CLI/App Server fix.

Should fix

1. [P2] Update Codex auth docs and env example

   docs/configuration.md and .env.example still describe the old behavior where local Codex transports implicitly use OPENAI_API_KEY / OPENAI_BASE_URL. After this PR, the intended contract is different:

   • Codex SDK/CLI/App Server should default to local Codex login/OAuth auth.
   • Codex API transport should continue using OPENAI_API_KEY + OPENAI_BASE_URL.
   • API-key-backed local Codex runs should require explicit profile apiKeyEnvVar or apiKey.
   • Local custom endpoint override should be documented as profile baseUrl or CODEX_BASE_URL.

   This should be fixed before merge or tracked as an explicit follow-up, because the current docs would lead users to configure the exact ambient env values this PR is trying to stop local transports from inheriting.

Nits

None.

Context gates

• Architecture: pass — the main implementation stays within runtime profile resolution and Codex adapter env construction.
• Package CHECKLIST: error — packages/runtime/CHECKLIST.md requires adapter parity; SDK was fixed, but CLI/App Server were left behind.
• Docs / skill contract sync: warn — docs and .env.example still describe old Codex auth defaults; no skill/prompt contract changes found.
• API/web/client sync: pass — no API/web schema changes found; existing runtime service paths still pass resolved baseUrl / apiKeyEnvVar only when present.
• Security surfaces: warn — not a direct secret leak in the reviewed diff, but CLI/App Server still expose ambient OPENAI_API_KEY to local Codex child processes by default.
• Feature flag / risk gating: n/a — this is a targeted auth-isolation bug fix; no new rollout flag appears necessary.
• Env / Turbo / process plumbing: error — process env filtering is inconsistent across Codex SDK/CLI/App Server, and current main has env/Turbo changes that require a rebase.
• Managed assets / ownership: n/a — no managed asset install/update/remove ownership behavior changed.
• Migration / backward compatibility: warn — the default behavior change is intentional, but docs need to state how API-key-backed local runs opt in explicitly.
• Dependency / lockfile / production install: warn — this PR does not touch dependencies, but current main changed lockfiles/manifests; rebase and rerun checks before merge.
• PR size / decomposition: pass — small, coherent diff: 6 files, 139 additions, 15 deletions.
• Stack / merge order / base freshness: error — branch is 32 commits behind current main.
• CI / audit: warn — Build, Lint, Tests, Security Audit, and MCP Unit are green for e549b76; AI Review is skipped; checks need to rerun after rebase.

Verification

• Checked: PR metadata, title/body, changed file list, commit diff, prior PR comments, runtime package checklist, SDK env handling, runtime profile resolution, CLI env builder, App Server env builder, current base freshness, and visible workflow runs.
• Checked: review criteria and required output format from the provided instructions.
• Ran locally: not run; review was performed through repository/GitHub inspection only.
• CI: Build, Lint, Tests, Security Audit, and MCP Unit passed on current head; AI Review was skipped.
• Not verified: live Codex OAuth behavior, live CLI/App Server child process behavior, the Windows ai:validate perf-harness spawn EINVAL failure, and post-rebase CI.

Verdict

Verdict: REQUEST_CHANGES until Codex CLI/App Server stop implicitly consuming ambient OPENAI_API_KEY, the branch is rebased onto current main, and CI passes on the rebased head.

[ichinya]

REQUEST_CHANGES until Codex CLI/App Server stop implicitly consuming ambient OPENAI_API_KEY, the branch is rebased onto current main, and CI passes on the rebased head.

[lee-to]

Since this PR has been inactive, we picked it up and addressed @ichinya's REQUEST_CHANGES review on a fresh branch off current main: fix/codex-oauth-env-isolation (commit a10b678).

Review items resolved

[P1] Local Codex CLI/App Server still consumed ambient OPENAI_API_KEY — fixed. The SDK isolation is now mirrored across all three local transports:

• sdk.ts — blocks OPENAI_API_KEY/OPENAI_BASE_URL from the child env and no longer infers apiKey/baseUrl from them; forwards only when a profile apiKeyEnvVar opts into API-key auth.
• cli.ts — buildCuratedEnv gates OPENAI_API_KEY (and any custom key var) behind an explicit opt-in (apiKeyEnvVar/apiKey); an explicit literal apiKey is injected directly instead of being inherited from process.env.
• appServer/process.ts — dropped the implicit process.env.OPENAI_API_KEY fallback and applied the same opt-in gate. Model discovery delegates to this builder, so it is covered too.
• resolution.ts — returns apiKeyEnvVar/apiKey as null for local Codex transports unless a profile sets them, and infers CODEX_BASE_URL (not OPENAI_BASE_URL) for local transports. The API transport is unchanged (still OPENAI_API_KEY + OPENAI_BASE_URL).
• Explicit apiKey, explicit apiKeyEnvVar, profile baseUrl, and CODEX_BASE_URL all remain honored.

[P1] Rebase onto current main — done. The work was re-applied on top of current main (the original fork branch was 32 commits behind and overlapped runtime/docs/env changes), so checks run against the real merge result.

[P2] Docs / .env.example — updated. docs/configuration.md (auth resolution list + env table + new CODEX_BASE_URL row), docs/providers.md (local-transport auth note), and .env.example now describe the OAuth-by-default contract and the explicit API-key / CODEX_BASE_URL opt-in.

Verification

• @aif/runtime: lint + build clean, 829 tests pass, coverage 85% (≥70% gate).
• @aif/api: runtimeService + runtimeProfiles suites pass (57 tests).
• New regression tests: SDK (2), CLI (3), App Server (4), profile resolution (5), model discovery (2); 3 existing tests that assumed the old leak behavior were updated to opt in explicitly.

Adapter parity: the hijack is Codex-specific (Claude/OpenRouter/opencode use their own auth and never consume an ambient OPENAI_API_KEY), so all affected paths are the three Codex local transports — all now covered, satisfying the runtime CHECKLIST.md parity rule.

[ichinya]

Requesting changes.

The SDK fix is good, but the PR still does not protect all local Codex transports as claimed. resolveRuntimeProfile() now avoids implicit OPENAI_API_KEY / OPENAI_BASE_URL for local Codex profiles, and the SDK child env now mirrors that behavior. However, CLI and App Server still rebuild child env from process.env and can still forward or inject ambient OPENAI_API_KEY.

Please make CLI/App Server match SDK behavior:

• block ambient OPENAI_API_KEY and OPENAI_BASE_URL by default;
• only use/forward an API key when apiKey or apiKeyEnvVar is explicitly configured;
• preserve explicit baseUrl / CODEX_BASE_URL;
• add regression tests for CLI and App Server env construction.

Docs / .env.example should also be updated so local Codex SDK/CLI/App Server profiles are documented as codex login / OAuth-first, while API transport keeps OPENAI_API_KEY + OPENAI_BASE_URL.

Verdict: REQUEST_CHANGES.

[lee-to]

The CLI/App Server blockers were already addressed in a10b678 (current PR head). Concretely, against current head — not the original fork commit:

• CLI (packages/runtime/src/adapters/codex/cli.ts) — buildCuratedEnv blocks ambient OPENAI_API_KEY by default. It is only forwarded when API-key auth is explicitly opted in via profile apiKeyEnvVar/apiKey (allowApiKey), and only when the configured key var is OPENAI_API_KEY (allowOpenAiApiKey gate). A custom apiKeyEnvVar is likewise blocked unless opted in. An explicit literal apiKey is injected directly, never inherited from process.env.
• App Server (packages/runtime/src/adapters/codex/appServer/process.ts) — same opt-in gate in buildCodexAppServerEnvWithStats. The implicit process.env.OPENAI_API_KEY fallback was removed: apiKey = explicitApiKey ?? (allowApiKey ? readString(process.env[apiKeyEnvVar]) : null). Model discovery delegates to this builder, so it is covered too.
• Resolution (resolution.ts) — returns apiKeyEnvVar/apiKey as null for local Codex transports unless a profile sets them; API transport is unchanged (OPENAI_API_KEY + OPENAI_BASE_URL).
• Docs — docs/configuration.md, docs/providers.md, and .env.example were updated in this same commit for the OAuth-by-default contract and the explicit API-key / CODEX_BASE_URL opt-in.
• Tests — regression coverage added for all three local transports; 73 tests pass across SDK/CLI/App Server/model-discovery suites (ambient OPENAI_API_KEY/OPENAI_BASE_URL absent by default; explicit apiKeyEnvVar/apiKey forwards; CODEX_BASE_URL honored; API transport unchanged).

The latest review text matches the 2026-05-13 review almost verbatim and describes the pre-fix code paths. Could you re-review against head a10b678? The specific lines cited as broken (CLI OPENAI_ allowlist forwarding, App Server apiKeyEnvVar default to OPENAI_API_KEY + process.env.OPENAI_API_KEY read) no longer exist as described.

[lee-to]

Pushed f386d46 addressing the review.

The CLI and App Server env isolation was already behaviorally correct at a10b678, but it was implemented with ad-hoc per-key if checks while OPENAI_API_KEY was left out of each builder's BLOCKED_ENV_KEYS set — which is what made the protection hard to verify from the blocklist alone (and is the only place the SDK lists it). This commit aligns all three local transports on one identical structure:

• cli.ts / appServer/process.ts — OPENAI_API_KEY now lives in BLOCKED_ENV_KEYS alongside OPENAI_BASE_URL, matching sdk.ts. The explicitly opted-in key var (apiKeyEnvVar/apiKey) is forwarded before the blocklist is consulted, so API-key auth still works when a profile requests it; everything else is blocked by default.
• No behavior change: ambient OPENAI_API_KEY / OPENAI_BASE_URL remain blocked unless API-key auth is explicitly opted in; explicit apiKey/apiKeyEnvVar, profile baseUrl, and CODEX_BASE_URL are still honored; API transport is unchanged.

This also satisfies the runtime adapter-parity checklist rule — all three local Codex transports (sdk, cli, app-server) now isolate ambient OpenAI auth env through the same blocklist pattern instead of three divergent implementations.

Verification: npm run ai:validate green (lint + build + tests/coverage + perf + protocol); the 73 SDK/CLI/App Server/model-discovery env-isolation tests pass.

[ichinya]

Re-checking the PR: verdict remains REQUEST_CHANGES.

The SDK path is fixed, but the local transport contract is still incomplete. The PR says local Codex transports (sdk, cli, app-server) should no longer inherit generic OpenAI API env defaults unless API-key auth is explicitly requested. The current implementation only fixes SDK/profile resolution.

CLI still allows OPENAI_ env vars and only blocks OPENAI_BASE_URL, so ambient OPENAI_API_KEY can still reach the Codex CLI child process. App Server still defaults apiKeyEnvVar to OPENAI_API_KEY, reads process.env[apiKeyEnvVar] / process.env.OPENAI_API_KEY, and writes it into the child env. This means OPENAI_API_KEY=sk-000 can still hijack OAuth-backed transport: "cli" or transport: "app-server" runs.

Please make CLI/App Server mirror SDK behavior:

• block ambient OPENAI_API_KEY and OPENAI_BASE_URL by default;
• only use/forward API keys when apiKey or apiKeyEnvVar is explicitly configured;
• preserve explicit baseUrl / CODEX_BASE_URL;
• add regression tests for CLI and App Server env construction;
• update docs / .env.example for the new Codex auth model.

Verdict: REQUEST_CHANGES.

[lee-to]

All five items in this review are already implemented at the current PR head f386d46. The review text describes the pre-f386d46 code (it is identical to the 2026-05-13 review), so I think it was generated against a stale checkout. Concrete proof against the live branch:

1. Block ambient OPENAI_API_KEY and OPENAI_BASE_URL by default — done. Both are now in the blocklist sets:

   • CLI: https://github.com/tuzer69/aif-handoff/blob/f386d46cd22f36ef2d979d6259c9430b60852048/packages/runtime/src/adapters/codex/cli.ts#L249
   • App Server: https://github.com/tuzer69/aif-handoff/blob/f386d46cd22f36ef2d979d6259c9430b60852048/packages/runtime/src/adapters/codex/appServer/process.ts#L38

   The review's claim that "CLI still allows OPENAI_ env vars and only blocks OPENAI_BASE_URL" no longer matches the code — OPENAI_API_KEY is listed first in that Set.

2. Only use/forward an API key when apiKey/apiKeyEnvVar is explicitly configured — done. The opt-in key var is forwarded before the blocklist; without opt-in it falls through to the blocklist and is dropped:

   • CLI opt-in gate: https://github.com/tuzer69/aif-handoff/blob/f386d46cd22f36ef2d979d6259c9430b60852048/packages/runtime/src/adapters/codex/cli.ts#L280
   • App Server opt-in gate: https://github.com/tuzer69/aif-handoff/blob/f386d46cd22f36ef2d979d6259c9430b60852048/packages/runtime/src/adapters/codex/appServer/process.ts#L119
   • App Server API-key resolution — no implicit process.env.OPENAI_API_KEY fallback; reads process.env[apiKeyEnvVar] only when allowApiKey: https://github.com/tuzer69/aif-handoff/blob/f386d46cd22f36ef2d979d6259c9430b60852048/packages/runtime/src/adapters/codex/appServer/process.ts#L146

   So OPENAI_API_KEY=sk-000 cannot reach a transport: "cli" or transport: "app-server" child without an explicit profile opt-in.

3. Preserve explicit baseUrl / CODEX_BASE_URL — done: https://github.com/tuzer69/aif-handoff/blob/f386d46cd22f36ef2d979d6259c9430b60852048/packages/runtime/src/adapters/codex/appServer/process.ts#L155 (and the same in cli.ts / sdk.ts).

4. Regression tests for CLI and App Server env construction — present and green. 95 tests pass across the SDK / CLI / App Server / model-discovery / resolution suites, covering: ambient OPENAI_API_KEY/OPENAI_BASE_URL absent by default; explicit apiKeyEnvVar/apiKey forwards; CODEX_BASE_URL honored; API transport unchanged.

5. Docs / .env.example — updated in a10b678: docs/configuration.md (auth resolution list + env table + CODEX_BASE_URL row), docs/providers.md (local-transport auth note), and .env.example (OAuth-by-default contract).

npm run ai:validate is green (lint + build + tests/coverage + perf + protocol).

Could you re-run the review against head f386d46? If a specific line in the current tree still allows an ambient OPENAI_API_KEY to reach a local Codex child, please point at it directly — I traced all three local transports and the only paths that set OPENAI_API_KEY in the child env are gated behind an explicit opt-in.

[lee-to]

Note for maintainers: the automated REQUEST_CHANGES reviews on this PR appear to be running against a stale checkout. The last three review comments are near-verbatim copies of the original 2026-05-13 review and quote code paths (CLI blocklist with only OPENAI_BASE_URL; App Server reading process.env.OPENAI_API_KEY) that no longer exist at the current head f386d46.

The current head already implements every requested item — ambient OPENAI_API_KEY/OPENAI_BASE_URL are blocked by default across all three local Codex transports (SDK/CLI/App Server), API keys are forwarded only on explicit apiKey/apiKeyEnvVar opt-in, baseUrl/CODEX_BASE_URL are preserved, regression tests cover CLI and App Server, and docs/.env.example are updated. npm run ai:validate is green. See the preceding comment for line-level permalinks.

Requesting a fresh re-review against f386d46 (or a human re-review). If any line in the current tree still lets an ambient OPENAI_API_KEY reach a local Codex child, please cite it directly — I was unable to find one.

[mifogeshi15617-commits]

Debi has thoroughly reviewed the PR. The isolation of ambient OpenAI env defaults (OPENAI_API_KEY/OPENAI_BASE_URL) is perfectly implemented across all three local transports (SDK, CLI, App Server). The regression tests cover all scenarios and verify complete parity. Prettier/ESLint are green, tests are green. Merging is highly recommended!

[ichinya]

Re-checking this: the original PR #125 / branch is no longer accessible from the current GitHub connector state, so I cannot verify a new head SHA. However, current main still contains the old Codex env behavior, so the original blocker remains relevant unless this fix was moved to another PR.

Verdict remains REQUEST_CHANGES.

The required behavior is:

• local Codex transports (sdk, cli, app-server) must not implicitly consume ambient OPENAI_API_KEY / OPENAI_BASE_URL;
• OPENAI_API_KEY should only be forwarded/used when apiKey, apiKeyEnvVar, or another explicit API-key opt-in is configured;
• CODEX_BASE_URL / explicit baseUrl should remain supported for local endpoint override;
• API transport should keep OpenAI-compatible API key + base URL behavior;
• regression tests must cover SDK, CLI, and App Server env construction.

Current main still forwards or infers these values in SDK/CLI/App Server paths, so this auth-isolation fix is not complete/landed there.

[lee-to]

@ichinya This review appears to be stale. PR #125 is accessible and its current head is
f386d46cd22f36ef2d979d6259c9430b60852048.

The requested behavior is implemented at that head:

• CLI blocks OPENAI_API_KEY and OPENAI_BASE_URL by default and only forwards
  the configured key var when apiKeyEnvVar / apiKey is explicitly set.
• App Server uses the same blocklist and opt-in gate; there is no implicit
  process.env.OPENAI_API_KEY fallback without allowApiKey.
• Resolution keeps local Codex transports on OAuth-by-default auth and only uses
  CODEX_BASE_URL / explicit baseUrl for local base URL override.
• API transport behavior remains unchanged.

So the latest REQUEST_CHANGES comment seems to have reviewed main, not the PR
head.

[ichinya]

Reviewed PR #125.

The PR addresses the Codex OAuth/env-isolation issue consistently across the runtime resolution layer and all local Codex transports.

What changed:

• Local Codex transports (sdk, cli, app-server) no longer implicitly consume ambient OPENAI_API_KEY / OPENAI_BASE_URL.
• Codex API transport behavior is preserved: it still uses OPENAI_API_KEY and OPENAI_BASE_URL.
• Explicit opt-in still works for local transports through profile apiKeyEnvVar or literal apiKey.
• CODEX_BASE_URL / profile baseUrl remain available for custom local Codex endpoints.
• SDK, CLI, and App Server env curation now share the same intended blocklist semantics for ambient OpenAI auth env.
• Docs and .env.example now explain the split between Codex API transport and local Codex OAuth-backed transports.

I checked the relevant implementation paths:

• packages/runtime/src/resolution.ts
• packages/runtime/src/adapters/codex/sdk.ts
• packages/runtime/src/adapters/codex/cli.ts
• packages/runtime/src/adapters/codex/appServer/process.ts

The test coverage added in the PR is good and covers the important regression cases:

• local Codex SDK/CLI profiles do not inherit ambient OPENAI_API_KEY / OPENAI_BASE_URL;
• Codex API transport still keeps the OpenAI env defaults;
• explicit apiKeyEnvVar opt-in still forwards the configured key;
• literal apiKey still gets injected for CLI/App Server;
• CODEX_BASE_URL / explicit baseUrl are preserved for local transports;
• model discovery/app-server env handling follows the same isolation rule.

I did not find blocking issues in the PR diff.

Validation note: in this Windows workspace, full npm run ai:validate initially hit unrelated local harness/runtime issues outside the PR diff. After local-only test/perf harness fixes, validation passed. Those local fixes are not part of this PR, so I am not treating them as PR changes.