Summary

• Problem: plugin LLM completions treated canonical openai/gpt-* model refs as direct OpenAI API calls, even when config mapped those refs to the Codex runtime.
• Why it matters: context-engine plugins such as lossless-claw could fail LLM summarization under Codex OAuth with a missing OPENAI_API_KEY, then fall back to deterministic truncation.
• What changed: completion runtime selection now preserves the logical model ref while routing execution through the configured runtime provider when the resolved agent runtime is Codex.
• What did NOT change: this does not grant plugins new model access or bypass model policy; it only makes plugin LLM completion honor the already-resolved runtime policy.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

Behavior addressed: lossless-claw doctor repair needed to use model-backed plugin LLM summarization while the active OpenClaw gateway was authenticated with OpenAI Codex OAuth, not a direct OPENAI_API_KEY.

Real environment tested: Josh's live OpenClaw gateway running this PR head, OpenClaw 2026.5.12-beta.1 (47697a7), Telegram group topic session agent:main:telegram:group:-1003774691294:topic:3731, model openai/gpt-5.5, runtime OpenAI Codex, auth openai-codex:josh@martian.engineering.

Exact steps or command run after this patch: deployed this PR branch locally, rebuilt and restarted the gateway, then ran /lossless doctor apply in the same Telegram/OpenClaw session that had a known fallback LCM summary repair candidate. Verified after the run with lcm_describe sum_22ef5580363377a1 and lcm_grep "LCM fallback summary".

Evidence after fix: before doctor apply, lcm_grep "LCM fallback summary" found recent repair candidate sum_22ef5580363377a1 in this session. After doctor apply, lcm_describe sum_22ef5580363377a1 returned a real summary instead of the fallback marker:

LCM_SUMMARY sum_22ef5580363377a1
meta conv=4754 kind=leaf depth=0 tok=656 descTok=0 srcTok=39920 desc=0 range=2026-05-12 08:14 PDT..2026-05-12 08:42 PDT budgetCap=4000
content
Codex GH auth is now working via symlinked isolated HOME/Keychains: `gh api user` returned `jalehman`, and `gh repo view openclaw/openclaw` returned `openclaw/openclaw MAINTAIN`. Best fix chosen was "make it work" by symlinking Codex HOME `.config/gh` and `Library/Keychains`, not host HOME isolation or launchd `GH_TOKEN`.

A separate issue appeared: `tools.toolSearch` was supposed to be disabled, but the gateway kept serving stale in-memory config...

The live session status for the proof run showed:

OpenClaw 2026.5.12-beta.1 (47697a7)
Model: openai/gpt-5.5
Auth: oauth (openai-codex:josh@martian.engineering)
Runtime: OpenAI Codex
Session: agent:main:telegram:group:-1003774691294:topic:3731

Observed result after fix: doctor apply repaired the fallback summary in place with model-generated summary content and did not hit the previous direct OpenAI auth failure path. The repaired summary no longer contains [LCM fallback summary], and a follow-up grep for LCM fallback summary no longer returned sum_22ef5580363377a1.

What was not tested: no direct OpenAI OPENAI_API_KEY configuration was tested, and no non-Codex agent runtime was changed by this live proof.

Before evidence (optional but encouraged): the pre-fix failure mode from the same environment was lossless summarizer auth failure for direct OpenAI provider traffic: Auth lookup failed for provider "openai": No API key found for provider "openai". You are authenticated with OpenAI Codex OAuth; OpenAI agent model runs use openai/gpt-* through the Codex runtime.

Root Cause (if applicable)

• Root cause: plugin LLM completion resolved openai/gpt-* as direct provider traffic even when the configured model policy mapped that OpenAI model ref to the Codex agent runtime.
• Missing detection / guardrail: tests covered direct provider completion preparation but not Codex-runtime-backed OpenAI refs through the plugin runtime.llm.complete path.
• Contributing context (if known): agent turns already worked with Codex OAuth, so the failure only surfaced inside plugin/context-engine summarization.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file:
  • src/agents/simple-completion-runtime.selection.test.ts
  • src/agents/simple-completion-runtime.test.ts
  • src/plugins/runtime/runtime-llm.runtime.test.ts
• Scenario the test should lock in: canonical openai/gpt-* refs preserve their logical identity while completion execution routes through Codex when resolved agent runtime policy says codex.
• Why this is the smallest reliable guardrail: it verifies runtime-provider selection at the completion seam without needing live OAuth credentials in CI.
• Existing test that already covers this (if any): new/updated tests in this PR cover the selection and preparation behavior.

User-visible / Behavior Changes

Plugin/context-engine LLM summarization now works with canonical OpenAI model refs that are configured to run through Codex OAuth. Users should no longer need to add OPENAI_API_KEY just to make plugin summarization work in a Codex-runtime OpenAI setup.

Diagram (if applicable)

Before:
lossless-claw -> runtime.llm.complete(openai/gpt-5.4-mini) -> direct OpenAI auth -> missing OPENAI_API_KEY -> fallback truncation

After:
lossless-claw -> runtime.llm.complete(openai/gpt-5.4-mini) -> resolved Codex runtime provider -> Codex OAuth -> model-backed summary repair

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local OpenClaw gateway
• Model/provider: openai/gpt-5.5 and openai/gpt-5.4-mini routed through Codex runtime/OAuth
• Integration/channel (if any): Telegram group topic
• Relevant config (redacted): OpenAI model refs configured with Codex agent runtime; lossless-claw summary model uses the OpenAI/Codex-backed runtime path.

Steps

1. Deploy this PR head and restart the gateway.
2. Run /lossless doctor apply in a session containing an LCM fallback summary candidate.
3. Inspect the repaired summary with lcm_describe <summary-id>.
4. Search for remaining fallback markers with lcm_grep "LCM fallback summary".

Expected

• Doctor apply invokes the model-backed plugin LLM summarizer through Codex runtime/OAuth.
• The fallback summary is replaced with a real summary.
• No direct OpenAI OPENAI_API_KEY auth failure appears.

Actual

• sum_22ef5580363377a1 was repaired in place and now contains coherent summary text instead of [LCM fallback summary].
• The active gateway/session was on PR head 47697a7 with OpenAI Codex OAuth.
• No direct OpenAI API-key auth failure was observed during the repair.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: live lossless doctor summary repair under Codex OAuth on this PR head; targeted unit/seam tests; changed-test and formatting/lint checks.
• Edge cases checked: OpenRouter model id preservation, runtime-provider selection, registry config compatibility guard.
• What you did not verify: direct OpenAI API-key mode and non-Codex runtime behavior in a live gateway.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: runtime-provider selection could accidentally change the provider used for non-Codex completion calls.
  • Mitigation: keep the logical model ref separate from the execution provider and cover OpenRouter/direct-provider preservation in tests.

Testing

• pnpm test src/agents/simple-completion-runtime.selection.test.ts -- --reporter=verbose
  • Passed: 7 tests
• pnpm test src/agents/simple-completion-runtime.test.ts -- --reporter=verbose
  • Passed: 16 tests
• pnpm test src/plugins/runtime/runtime-llm.runtime.test.ts -- --reporter=verbose
  • Passed: 17 tests
• pnpm test:changed
  • Passed: 2 Vitest shards
• pnpm format:check -- CHANGELOG.md src/agents/simple-completion-runtime.ts src/agents/simple-completion-runtime.test.ts src/agents/simple-completion-runtime.selection.test.ts
  • Passed
• node scripts/run-oxlint.mjs --tsconfig config/tsconfig/oxlint.core.json src/agents/simple-completion-runtime.ts src/agents/simple-completion-runtime.test.ts src/agents/simple-completion-runtime.selection.test.ts
  • Passed: 0 warnings, 0 errors
• git diff --check
  • Passed

Known gap: pnpm check:changed currently fails in untouched src/plugins/registry.runtime-config.test.ts type assertions, unrelated to this diff.