raft-pi-auth-issue.md

raft-pi-auth-issue.md

[Raft Computer 1.0.18][macOS arm64] Local Pi fails to use OpenAI Codex OAuth in the SEA build

Summary

An agent configured with the Local Pi runtime and an existing openai-codex OAuth credential cannot answer any prompt. The failure occurs before a provider request is made.

Raft Computer 1.0.18 improved the diagnostic compared with 1.0.13, but did not fix the failure. The current error shows that the Node SEA bundle attempts to dynamically import openai-codex.js from its temporary extraction directory, where that file does not exist.

The independently installed Pi CLI can derive an OpenAI Codex bearer from the same credential, so the credential itself is not the failing boundary.

Environment

• OS: macOS, Apple Silicon (darwin-arm64)
• Raft Computer: 1.0.18
• Previous affected Raft Computer version: 1.0.13
• Selected runtime in the Raft UI: Local Pi (runtime=pi), not Built-in Pi
• Selected model: openai-codex/gpt-5.6-terra
• Authentication: existing ChatGPT subscription OAuth credential in the normal Pi agent directory
• Independently installed Pi CLI: @earendil-works/pi-coding-agent 0.84.3
• Pi SDK embedded in Raft Computer 1.0.18: @earendil-works/pi-ai 0.83.0

No credential values are included in this report.

Reproduction steps

1. On macOS arm64, install Pi and authenticate the openai-codex provider with a ChatGPT subscription.
2. Verify that Pi reports the openai-codex credential as configured.
3. In Raft, configure a managed agent to use Local Pi.
4. Select openai-codex/gpt-5.6-terra.
5. Start or restart the agent after installing Raft Computer 1.0.18.
6. Send the agent any prompt.
7. Inspect the resulting Pi session JSONL or the runtime error event.

Expected behavior

The Local Pi agent should derive authentication from the existing Pi OAuth credential and send the model request.

Actual behavior

The first assistant event immediately ends with stopReason=error and no content:

OAuth auth derivation failed for openai-codex: Cannot find module
'.../raft-computer-sea/darwin-arm64/openai-codex.js'
imported from
'.../raft-computer-sea/darwin-arm64/computer-bundle.cjs'

The failure happens during OAuth auth derivation, before a model response is produced.

Reproducibility

• Raft Computer 1.0.13: 8 consecutive prompt attempts failed immediately with the generic error OAuth auth derivation failed for openai-codex.
• Raft Computer 1.0.18: a fresh agent session failed immediately with the more specific missing-module cause shown above.

Investigation and attempts already made

1. Confirmed that Local Pi was selected

The Raft UI showed Local Pi selected. Built-in Pi was not selected.

2. Verified the same OAuth credential outside Raft

With Raft's SEA-specific PI_PACKAGE_DIR removed from the standalone CLI environment, Pi 0.84.3 successfully derives the bearer:

env -u PI_PACKAGE_DIR pi auth print-bearer-token \
  --provider openai-codex \
  --model gpt-5.6-terra \
  >/dev/null

Observed exit code: 0.

An earlier standalone end-to-end request using the same credential and model also succeeded. During the final post-upgrade check, a separate standalone completion attempt ended with fetch failed; therefore the fresh verification claim is limited to successful OAuth derivation, not current network completion.

3. Upgraded Raft Computer

Raft Computer was upgraded from 1.0.13 to 1.0.18 and the managed agent was started in a new session.

Result: still fails. The upgrade changed the embedded Pi SDK from 0.80.10 to 0.83.0 and preserved the underlying cause in the error message, revealing the missing dynamic import.

4. Checked whether Local Pi launches the installed Pi executable

Inspection of the shipped 1.0.18 binary shows:

• runtime=pi maps to PiDriver;
• PiDriver.createSession() creates PiSdkRuntimeSession;
• PiDriver.spawn() rejects child-process execution with PiDriver uses a native RuntimeSession; child-process spawn is unsupported.

Therefore Local Pi currently uses the Pi SDK embedded in raft-computer; it does not execute the independently installed Pi 0.84.3 CLI. Pointing an agent environment variable at a local Pi working directory cannot change this execution path.

5. Investigated PI_PACKAGE_DIR

Raft Computer injects a SEA runtime package directory through PI_PACKAGE_DIR. That directory is incomplete for directly launching the standalone interactive Pi CLI and can produce missing theme-asset errors.

This is a separate issue. It is not the direct cause of the managed-agent OAuth failure because the current Local Pi driver does not spawn the local CLI.

6. Inspected the Botiverse Pi SEA patch

botiverse/pi-coding-agent 0.83.0-botiverse.0 applies virtualModules to Pi's jiti extension loader under Node SEA and references Raft issue botiverse/slock#6112.

That patch addresses extension module resolution. The failure reported here occurs in @earendil-works/pi-ai's lazy OAuth flow import, so the extension-loader patch alone does not cover this path. Raft Computer 1.0.18 also appears to embed upstream @earendil-works/pi-coding-agent 0.83.0 rather than the Botiverse alias.

Root-cause evidence

The embedded Pi 0.83 OAuth loader behaves as follows:

1. openaiCodexProvider() uses a lazy OAuth loader.
2. If bundled OAuth loaders have not been registered, it dynamically imports ./openai-codex.js.
3. In the Node SEA build, that relative import resolves beside the extracted computer-bundle.cjs.
4. openai-codex.js is not present there, so auth derivation fails with ERR_MODULE_NOT_FOUND.

The 1.0.18 binary contains the lazy-import code, but inspection found no registerBundledOAuthFlowLoaders or registerBunOAuthFlows registration marker.

Suggested fix

Before any Pi ModelRuntime or agent session is created in the Node SEA process, statically bundle and register all Pi OAuth flow loaders.

Pi already provides the registration used by its standalone binary:

import { registerBunOAuthFlows } from "@earendil-works/pi-ai/bun-oauth";

registerBunOAuthFlows();

Despite the export name, this function registers statically imported OAuth implementations through registerBundledOAuthFlowLoaders(...); that is the behavior needed by a Node SEA bundle as well.

An equivalent Raft-owned registration is also valid, but it should cover every bundled OAuth provider rather than special-case only OpenAI Codex.

Alternative product direction: make Local Pi genuinely launch the installed Pi RPC entry point in a child process. If that approach is chosen, remove the SEA-specific PI_PACKAGE_DIR from the child environment. This is a larger runtime architecture change and is not required for the minimal SEA OAuth fix.

Recommended regression coverage

1. Build the production Node SEA artifact with no adjacent node_modules or extracted Pi OAuth source files.
2. Start both Local Pi and Built-in Pi session paths with a stored OAuth credential.
3. Exercise auth resolution for every bundled OAuth provider, including openai-codex.
4. Assert that auth resolution does not attempt a filesystem-relative dynamic import.
5. For OpenAI Codex, verify that a valid stored credential reaches a mocked or controlled provider request boundary.
6. Preserve the underlying error cause in runtime/session diagnostics.

Impact

Managed agents configured with Local Pi cannot use ChatGPT subscription authentication through openai-codex. Every prompt fails before model execution, so the runtime is unusable for this authentication mode.