MCP servers not being triggered after upgrading from 2026.5.7 to 2026.5.12 / Codex runtime from PI

[slender rampart]

Hi, after upgrading OpenClaw from 2026.5.7 to 2026.5.12, my MCP servers/tools do not seem to trigger like they used to.

Before the update, I had context-mode, Serena, and Graphify installed and working. OpenClaw would use them pretty often during coding/workspace tasks.

After the update, MCP usage dropped a lot. Context-mode and Serena are barely called now, or sometimes not at all.

I noticed that after the move from PI to Codex, there is now a Codex-specific folder here:

C:\Users\user.openclaw\agents\main\agent\codex-home
It seems like Codex may be using config/context from that folder instead of my normal agent workspace setup.

My main workspace AGENTS.md already has my MCP/tooling instructions for context-mode, Serena, and Graphify. But after the update, Codex does not seem to follow that file the same way. It feels like I may need a separate AGENTS.md inside codex-home, and maybe hooks/tool setup there too.

Expected

OpenClaw/Codex should keep using my existing workspace AGENTS.md, MCP servers, and tool instructions after upgrading.

Actual
MCP servers/tools barely trigger, or do not trigger at all
Context-mode and Serena usage dropped noticeably
Codex seems to use codex-home
My normal workspace AGENTS.md seems to have less effect
I may need to duplicate hooks/tool instructions, but I’m not sure
Questions
Is codex-home supposed to have its own AGENTS.md?
Should Codex still read the main workspace AGENTS.md?
Do MCP/tool instructions or hooks need to be moved/duplicated?
Is there a PI → Codex migration step?
How can I verify which MCP servers Codex can see/use?
Did MCP/tool triggering behavior change in 2026.5.12?
Environment

Previous version: 2026.5.7
Current version: 2026.5.12
Agent: main
OS: Windows
Codex folder: C:\Users\user.openclaw\agents\main\agent\codex-home

This worked much better before the update, so I’m trying to figure out if this is expected behavior, a migration/config issue, or a bug.

[sick stirrup]

Short version: this sounds more like a Codex-runtime migration/config boundary than “MCP is broken”.

A few verified points from current docs/source:

• codex-home is expected. It is a per-agent Codex runtime area for Codex account/config/skills/plugins/native thread state, not the main OpenClaw workspace. It should not replace your workspace.
• You generally should not need to duplicate your workspace AGENTS.md into codex-home. OpenClaw workspace files still matter; for native Codex harness sessions, Codex loads AGENTS.md through its own project-doc discovery, while OpenClaw forwards the other bootstrap files as Codex config instructions.
• Codex CLI’s native $CODEX_HOME/skills is not one of OpenClaw’s normal skill roots. If you had useful Codex/CLI-local skills or plugins, use the migration path rather than manually copying random state.
• MCP/tool triggering did change shape: PI tool search is a PI surface. Codex harness runs use Codex-native code mode/tool search/dynamic tools, and Codex owns native shell/patch/MCP/native app tool calls. So “called less often” can be expected behavior, but “cannot see the MCP servers” is a config/runtime issue.

Checks I’d run:

openclaw status --all
openclaw doctor --fix

Then in the affected chat/thread:

[sick stirrup]

/status
/codex status
/codex mcp
/codex skills

/status should confirm whether the session is actually on Runtime: OpenAI Codex. /codex status reports app-server connectivity, account, rate limits, MCP servers, and skills. /codex mcp lists Codex app-server MCP status.

For migration/inventory:

openclaw migrate codex --dry-run

That inventories Codex CLI state from ~/.codex or CODEX_HOME; on Windows, point it explicitly if needed:

[sick stirrup]

openclaw migrate codex --dry-run --from "C:\\Users\\user\\.codex"

If the affected session existed before the runtime/config change, start fresh before judging it:

/new

or

/reset

Also make sure the current Codex session is bound to the intended project/workspace if you’re using project-local AGENTS.md/MCP assumptions:

[sick stirrup]

/codex bind --cwd <project-path>

Docs:
https://docs.openclaw.ai/plugins/codex-harness
https://docs.openclaw.ai/concepts/system-prompt
https://docs.openclaw.ai/concepts/agent-workspace
https://docs.openclaw.ai/tools/skills
https://docs.openclaw.ai/cli/migrate
https://docs.openclaw.ai/cli/mcp

If /codex mcp shows the servers missing or errored after doctor --fix and a fresh /new, that’s worth filing as a GitHub issue with the redacted openclaw status --all output and the /codex status / /codex mcp summaries: https://github.com/openclaw/openclaw/issues

[slender rampart]

is it suppose to be like this "MCP servers: codex app-server mcpServerStatus/list timed out Skills: 1" "MCP servers:
codex＿apps" for /codex status and /codex mcp I have a lot more skills in my agents workshop file also the mcp servers are showing up for context mode or serena it look slike

[sick stirrup]

No, the timeout part is not the healthy/expected state.

Two separate things are getting mixed together:

• Skills: 1 in /codex status is Codex app-server/native skills, not necessarily the same count as OpenClaw workspace skills from Skill Workshop. OpenClaw workspace skills still flow through OpenClaw’s skill loader, but native Codex app-server launches use an isolated per-agent CODEX_HOME, so personal Codex CLI skills are not implicitly loaded there.
• /codex mcp is listing what the Codex app-server sees. If it only shows codex_apps, then Codex currently only sees that native/app MCP surface. Serena/context-mode are not showing up in the Codex app-server MCP list.

The important line is:

MCP servers: codex app-server mcpServerStatus/list timed out

That means OpenClaw asked the Codex app-server for MCP status and the request timed out. I’d treat that as a Codex harness/app-server status problem, not normal behavior.

Next checks:

[sick stirrup]

/status
/codex status
/codex mcp
/codex skills
/mcp show

And on the machine:

openclaw status --all
openclaw doctor --fix
openclaw logs --follow
openclaw migrate codex --dry-run

[sick stirrup]

If you had Serena/context-mode configured in your old Codex CLI home, run the migration dry-run against that source explicitly on Windows:

openclaw migrate codex --dry-run --from "C:\\Users\\user\\.codex"

After any config/migration change, restart the gateway and use /new or /reset in this thread before retesting, because existing sessions can stay pinned to old runtime/thread state.

If /codex mcp still times out after that, please file it with the redacted openclaw status --all output plus the exact /codex status and /codex mcp output: https://github.com/openclaw/openclaw/issues

[slender rampart]

I installed serena and context mode natively for openclaw not on the old codex cli home

[sick stirrup]

Ah, thanks. Then ignore the old Codex CLI-home migration angle for Serena/context-mode.

If Serena/context-mode were installed natively as OpenClaw MCP servers, the key check is:

/mcp show

or on the host:

openclaw mcp list
openclaw mcp show --json

Those should show Serena/context-mode under OpenClaw mcp.servers.

[sick stirrup]

For Codex harness runs, OpenClaw is supposed to project user-configured mcp.servers into Codex’s mcp_servers thread config. So if /mcp show lists Serena/context-mode but /codex mcp only shows codex_apps, I’d suspect one of these:

• the current Codex thread was created before the MCP config existed/changed; use /new or /reset
• tools/bundle MCP are disabled by profile/config, e.g. minimal tool profile or tools.deny: ["bundle-mcp"]
• the server config uses a transport/shape the Codex projection/runtime is skipping
• the Codex app-server status call is unhealthy, which matches your mcpServerStatus/list timed out line

Also: Skill Workshop skills and MCP servers are separate. Having many skills in the workspace does not mean /codex skills will show the same number. /codex skills is Codex app-server/native skill status; OpenClaw workspace skills are loaded by OpenClaw’s skill system.

I’d run this exact sequence after a gateway restart:

/mcp show
/status
/new
/codex status

[sick stirrup]

/codex mcp

If /mcp show has Serena/context-mode and fresh /codex mcp still only has codex_apps or times out, that is looking like a Codex harness projection/status bug. Grab redacted openclaw status --all plus openclaw logs --follow around the /codex mcp call and file it here: https://github.com/openclaw/openclaw/issues

[slender rampart]

yeah /mcp show has context mode and serena but /codex mcp just shows codex_apps is it just because it's only showing stuff installed just for codex and not what's on openclaw? I had to enable something for /mcp show to even work

[sick stirrup]

Not quite. /codex mcp is Codex app-server MCP status, but it is not supposed to be limited only to things “installed just for Codex” in all cases.

For native Codex harness runs, OpenClaw should project user-configured OpenClaw mcp.servers into the Codex thread config as mcp_servers. So if:

/mcp show

shows Serena + context-mode, but:

/codex mcp

only shows:

[sick stirrup]

codex_apps

then the OpenClaw MCP registry exists, but it is not being reflected into the active Codex app-server thread.

The thing you enabled for /mcp show is probably just the chat command permission for managing/showing OpenClaw MCP config. That affects whether the slash command is allowed; it should not by itself be the runtime switch that makes Codex use those MCP servers.

Try this once, in order:

/status
/new
/codex status
/codex mcp

[sick stirrup]

If it still only shows codex_apps, check config for anything that would hide bundled MCP/tools from the run:

• minimal tool profile
• tools.deny: ["bundle-mcp"]
• per-agent tool restrictions on main
• unsupported MCP transport/shape for Serena/context-mode

Also, since you previously saw mcpServerStatus/list timed out, I’d treat this as likely bug territory if a fresh session still behaves the same. The strongest issue report would include:

openclaw --version
openclaw status --all
openclaw mcp show --json
openclaw logs --follow

Run /codex mcp while logs are following, then include the redacted log lines around that timeout. File here: https://github.com/openclaw/openclaw/issues

[slender rampart]

yeah it still shows codex＿apps and I dont think I hvae anything that would hide MCP/tools form the run

[sick stirrup]

Given that /mcp show has Serena/context-mode, a fresh Codex session still only shows codex_apps, and you don’t knowingly deny bundle MCP/tools, I’d treat this as a likely Codex harness MCP projection bug or an unsupported server-shape edge case.

One last useful local check is to compare the exact MCP server shapes without secrets:

openclaw --version
openclaw mcp show --json
openclaw config get tools
openclaw config get agents.list
openclaw config get agents.defaults

Redact tokens/env values before sharing. The main thing to inspect is whether Serena/context-mode are stdio servers with command + args, or HTTP/SSE/streamable HTTP. If they are non-stdio or have an unusual shape, that may explain why PI saw them but Codex projection/status does not.

At this point I’d file an issue with:

• exact openclaw --version