#codex plugin module not found / migration
coarse violet
Do you happen to know why this is happening?
IIRC this was fixed a few betas ago right?
jovial bone
let me diagnose
jovial bone
iirc this was migration related right?
migration? i havent migrated from anything. this started a few versions ago
coarse violet
Like is this a fresh onboard with no pre existing setup? Sorry if i'm totally missing things
jovial bone
Short version: this does not look like a Codex GPT model-name mismatch. openai/gpt-5.5 is being accepted far enough to route into the Codex harness. The failure happens earlier, while loading the Codex plugin runtime, before any OpenAI OAuth/model call can actually happen.
The root cause appears to be a missing package export for openclaw/plugin-sdk/codex-native-task-runtime. The installed Codex plugin imports that path, and the runtime file does exist on disk, but OpenClaw’s package.json#exports does not expose it. A direct file import works, but the package subpath import fails with ERR_PACKAGE_PATH_NOT_EXPORTED. Then OpenClaw’s Jiti/root-alias loader makes it worse: because there is no exact alias for openclaw/plugin-sdk/codex-native-task-runtime, it falls through to the bare openclaw/plugin-sdk alias and resolves the import as root-alias.cjs/codex-native-task-runtime, producing the MODULE_NOT_FOUND seen in the fallback logs.
So the precise maintainer-facing diagnosis is: @openclaw/codex@2026.5.12-beta.2 depends on a plugin SDK subpath that the matching openclaw@2026.5.12-beta.2 package builds but does not export. The likely fix is to add codex-native-task-runtime to the plugin SDK entrypoint/export manifest so package exports and root-alias exact aliases include it. A good regression test would import openclaw/plugin-sdk/codex-native-task-runtime from inside the installed Codex plugin and then run a Codex smoke request asserting the final provider stays openai/Codex instead of falling back. Secondary issue: the trace says the Anthropic fallback won but reports fallbackUsed: false, which is misleading telemetry.
jovial bone
Like is this a fresh onboard with no pre existing setup? Sorry if i'm totally mi...
no, its months old
5.5 was working early may / end of April
coarse violet
If i put up a PR to fix, would you be able to test @jovial bone ? I wanna nip this in the bud
jovial bone
i have about 20 minutes, enough time? 2 am here
neat moat
Got this same ReferenceError: Cannot access 'testClientFactoryStorage' before initialization on 2026.5.12-beta.2
coarse violet
yes please let me cook. How can I repro this? Just install the beta?
neat moat
Yeah I was upgrading from 2026.5.12-beta.1 -> 2026.5.12-beta.2
coarse violet
PR will be up in 2 minutes
neat moat
@autumn shuttle is https://github.com/openclaw/openclaw/pull/81148 an attempted fix for this?
coarse violet
neat moat
testing
jovial bone
testing
autumn shuttle
<@971122101782192180> is https://github.com/openclaw/openclaw/pull/81148 an atte...
Yes
coarse violet
^ according to codex, it proved that it was broken before, and fixed after my pr
Could you guys confirm?
neat moat
i just downgraded back to -beta.1, upgraded to -beta.2 and confirmed i was able to repro
so now downgrading to -beta.1, upgrading to your PR, and then validating
jovial bone
still waiting. seems it might be an npm issue
coarse violet
Any updates on testing https://github.com/openclaw/openclaw/pull/81206 ?
jovial bone
The PR gateway is now live and healthy from commit 09188368. One interesting thing already changed in the logs: the old MODULE_NOT_FOUND is gone, and Codex is now reaching the OpenAI request layer, where a separate tool-schema validation error appears on some cron/tool-heavy turns. I’m running the fresh direct smoke now to separate those two issues cleanly.
neat moat
i got same error but think i may have been testing the wrong codex plugin
investigating
coarse violet
Apparently beta 3 just got released, and codex is telling me the 2 commits in it were targetted at fixing this too
Plain answer: beta.3 is more correct for real users because it handles packed npm. Our PR is more correct on the trust boundary, but incomplete without beta.3’s packaging fix.
Probably worth testing b3
jovial bone
> Plain answer: beta.3 is more correct for real users because it handles packed ...
it was the packaging thats making it take so long
jovial bone
I’ve got the report shape now: beta.3 installs and runs, and the original Codex MODULE_NOT_FOUND is gone in real agent execution. The remaining actionable beta.3 issue is that the OpenAI/Codex primary route times out and silently falls back, while trace metadata still claims no fallback.
I filed the beta report here: openclaw/openclaw#81213
Headline result: beta.3 fixes the previous Codex MODULE_NOT_FOUND runtime-loader failure, but the OpenAI/Codex primary route still does not complete. It now times out on openai/gpt-5.5 and falls back to Anthropic/Pi, while the metadata misleadingly reports fallbackUsed: false.