Best possible solution:

Preserve explicit per-app disables while allowing the intended default-disabled base profile case, with regression coverage for both and real Codex thread proof before merge.

Do we have a high-confidence way to reproduce the issue?

Yes from source: current main skips a configured, ownership-proven app when Codex reports isEnabled = false, and upstream Codex allows per-thread config to enable a specific app. I did not run a live Codex thread repro in this read-only review.

Is this the best way to solve the issue?

No: dropping the enabled check fixes the base-default case but also bypasses explicit per-app disables because Codex reports both through the same isEnabled field. The safer fix needs to preserve explicit app disables or get an enablement-source signal before allowing the override.

Full review comments:

• [P1] Preserve explicit app disables — extensions/codex/src/app-server/plugin-thread-config.ts:235
AppInfo.isEnabled is not only a base-default signal; Codex computes it from both [apps._default] and explicit [apps.<id>] overrides. After this change, an operator who set a specific plugin-owned app to enabled = false still gets an OpenClaw thread config with that app forced to enabled: true, so the patch bypasses an existing app-level disable instead of only allowing the disabled-default case.
  Confidence: 0.89

Overall correctness: patch is incorrect
Overall confidence: 0.88

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 6343e1483faf.

Label justifications:

• P2: This is a focused Codex gateway-thread bug fix with a concrete merge blocker and limited affected surface.
• merge-risk: 🚨 compatibility: The diff changes how existing Codex app enablement config is interpreted for configured plugin-owned apps.
• merge-risk: 🚨 security-boundary: Ignoring isEnabled can expose app tools despite an explicit per-app disabled setting, affecting a tool-access boundary.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦪 silver shellfish and patch quality is 🧂 unranked krab.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body lists unit tests, formatting, build, runtime-postbuild, and diff-check output, but no real Codex operator-thread proof; contributors should redact private details such as tokens, IP addresses, phone numbers, and non-public endpoints before adding terminal output, logs, or a recording. After updating the PR body, a fresh ClawSweeper review should run automatically; if it does not, a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

PR surface:

Source 0, Tests -2. Total -2 across 2 files.

Security concerns:

• [medium] Explicit app disable can be bypassed — extensions/codex/src/app-server/plugin-thread-config.ts:235
  Because Codex reports both default-disabled and explicitly app-disabled state through isEnabled, removing this guard can enable a plugin-owned app in the thread even when the operator disabled that exact app in Codex config.
  Confidence: 0.86

What I checked:

• Current OpenClaw guard: Current main skips plugin-owned apps unless they are both accessible and enabled, and force-refreshes app inventory when either readiness condition is false. (extensions/codex/src/app-server/plugin-thread-config.ts:234, 6343e1483faf)
• Inventory mapping: OpenClaw maps Codex AppInfo.isAccessible and AppInfo.isEnabled directly into the owned app's accessible and enabled fields before thread config is built. (extensions/codex/src/app-server/plugin-inventory.ts:298, 6343e1483faf)
• Thread config call path: The plugin thread config patch is built during Codex app-server startup and merged into thread/start config, so setting apps.<id>.enabled = true becomes the per-thread grant. (extensions/codex/src/app-server/thread-lifecycle.ts:762, 6343e1483faf)
• Codex dependency contract: Upstream Codex documents AppInfo.is_enabled as whether the app is enabled in config.toml, and AppConfig.enabled is the per-app config field; this does not distinguish default-disabled from explicitly app-disabled state. (codex-rs/app-server-protocol/src/protocol/v2/apps.rs:91, 354807920e0b)
• Codex enablement semantics: Upstream Codex app_is_enabled computes enablement from [apps._default] plus [apps.<id>] overrides, and tests cover both default-disabled/per-app-enabled and per-app-disabled behavior. (codex-rs/connectors/src/app_tool_policy.rs:81, 354807920e0b)
• Live PR evidence: The PR body lists focused Vitest, format, build, runtime-postbuild, and diff-check commands, but no terminal/log/recording proof from a real Codex gateway thread. (f42ae600bf5b)

Likely related people:

• kevinslin: Remote commit metadata shows native plugin app support, stale app snapshot handling, and remote app-server plugin work touching the affected Codex app-thread config files. (role: Codex plugin app feature contributor; confidence: high; commits: a1ac559ed7e6, f169e0aafde8, bc5081c58730; files: extensions/codex/src/app-server/plugin-thread-config.ts, extensions/codex/src/app-server/plugin-thread-config.test.ts, extensions/codex/src/app-server/plugin-inventory.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.