LCM summarizer cannot resolve OAuth-based provider credentials after #163 fix (v0.5.1)

[sene1337]

Summary

After the fix in PR #163 (v0.5.1), configuring summaryProvider: "openai-codex" with summaryModel: "gpt-5.4" results in compaction auth failures and 60-second timeouts. The summarizer correctly avoids inheriting the runtime session auth profile (per #162 fix), but then has no auth path to resolve credentials for OAuth-based providers like openai-codex.

Environment

• OpenClaw: 2026.3.23-2
• lossless-claw: 0.5.1
• Host: macOS arm64 (Apple Silicon)
• Summary config:

  {
    "summaryProvider": "openai-codex",
    "summaryModel": "gpt-5.4"
  }

• Auth profile for openai-codex: OAuth-based (access, refresh, expires, accountId) — no API key

Expected behavior

When an explicit summaryProvider is configured and that provider uses OAuth auth (stored in per-agent auth-profiles), the summarizer should be able to resolve credentials and complete summarization.

Actual behavior

Compaction fails repeatedly with:

[lcm] summarizer timed out; provider=openai-codex; model=gpt-5.4; timeout=60000ms
[lcm] compaction failed: provider auth error. Check that the configured summaryProvider has valid API credentials. Current: openai-codex/gpt-5.4

The main session uses openai-codex without issue — chat completions work fine because the core runtime resolves the OAuth token from auth-profiles.json. But LCM's summarizer, after #163's fix correctly strips the inherited auth profile, ends up with authProfileId = undefined and cannot resolve the OAuth credential on its own.

Root cause analysis

The fix in #163 was correct for its target problem (auth drift from wrong inherited profiles). However, it created a new gap:

1. Pre-fix: avoid summarizer auth-profile leakage #163: summarizer inherited the runtime auth profile → worked for OAuth providers (but drifted when multiple agents had different profiles, as reported in LCM summarizer inherits runtime authProfileId and causes summary auth drift #162)
2. Post-fix: avoid summarizer auth-profile leakage #163: summarizer strips inherited auth profile when explicit summaryProvider is set → authProfileId becomes undefined → getApiKey() with no profile ID cannot find OAuth credentials → auth fails → 60s timeout → fallback to truncation

The openai-codex provider in OpenClaw uses OAuth by default (not API keys). The credentials live in per-agent auth-profiles.json files and require an authProfileId to resolve. With that stripped, there's no path to the token.

Workaround

Switch summaryProvider to a provider that uses a standard API key (e.g., openrouter with anthropic/claude-sonnet-4-6), which resolves via the provider config's apiKey field without needing an auth profile.

Suggested fix

When the summarizer has an explicit summaryProvider configured:

1. Don't inherit the runtime session's auth profile (current behavior, correct)
2. But do attempt to resolve the auth profile that matches the configured summaryProvider — e.g., look up the default auth profile for that provider, or accept an optional summaryAuthProfile config field
3. Alternatively, document that OAuth-based providers are unsupported for LCM summarization and require API-key-based providers

Related

• LCM summarizer inherits runtime authProfileId and causes summary auth drift #162 — original auth drift issue (fixed by fix: avoid summarizer auth-profile leakage #163)
• fix: avoid summarizer auth-profile leakage #163 — the fix that introduced this gap
• Constant Compaction Timeouts #160 — compaction timeout reports (likely some users hitting this same auth gap)

[100yenadmin]

Additional field evidence and scope expansion from a live OpenClaw integration deep-dive:

What we confirmed

The correct fix surface is broader than summaryProvider/summaryModel alone.

Lossless Claw already goes through OpenClaw's runtime completion path via deps.complete(...) in src/summarize.ts; this is not a case where LCM needs to manually call the gateway HTTP API.

The real gap is that Lossless Claw's summarizer / expansion resolution path does not yet cleanly support runtime-managed OAuth providers (especially openai-codex) as first-class backends.

Important expansion of scope

This should cover both:

1. Compaction summarization

   • summaryModel
   • summaryProvider

2. Delegated expansion / recall

   • expansionModel
   • expansionProvider
   • lcm_expand_query / delegated sub-agent flows

If we only fix summarization, we'll end up with an inconsistent system where compaction can use Codex OAuth but expansion cannot.

Likely technical cause

In src/summarize.ts, candidate resolution does the right high-level thing:

• resolve model/provider via deps.resolveModel(...)
• invoke the model via deps.complete(...)

But the credential path still appears biased toward direct API-key lookup:

• deps.getApiKey(provider, model, lookupOptions)
• optional authProfileId
• providerApi derived from legacy config lookup

That works fine for classic API-key providers, but is brittle for providers that are runtime-managed OAuth providers (like openai-codex) where:

• the auth path is not a normal static API key
• the provider requires the correct provider API (openai-codex-responses)
• the runtime already knows how to use the provider if deps.complete(...) is given the right resolved provider/model context

What the patch likely needs

A. Runtime-managed OAuth support in summarizer path

When summaryModel resolves to a provider like openai-codex, the summarizer path should be able to rely on runtime-managed auth via deps.complete(...) rather than assuming a direct provider API key is required.

B. Preserve provider API correctly

For openai-codex, ensure the completion path preserves the provider API (openai-codex-responses) instead of accidentally degrading into a generic OpenAI-style call shape.

C. Apply the same logic to expansion

The same runtime-managed OAuth support needs to apply to:

• expansionModel
• expansionProvider
• delegated lcm_expand_query paths

D. Make summarizer timeout configurable

The current hardcoded per-call summarizer timeout in src/summarize.ts is 60000ms. In large sessions, that is often too low even when the provider is otherwise correct. A config surface like summaryTimeoutMs / expansionTimeoutMs would help a lot.

Suggested expected behavior

These should work when OpenClaw has valid Codex OAuth configured:

{
  "summaryProvider": "openai-codex",
  "summaryModel": "gpt-5.4",
  "expansionProvider": "openai-codex",
  "expansionModel": "gpt-5.4"
}

and also:

{
  "summaryModel": "openai-codex/gpt-5.4",
  "expansionModel": "openai-codex/gpt-5.4"
}

Why this matters

This is the cleanest way for Lossless Claw to work with OpenClaw long-term:

• no manual gateway HTTP hacks
• no duplicated provider auth logic inside LCM
• full reuse of runtime-managed OAuth providers, especially Codex OAuth

[100yenadmin]

Update: I opened and substantially expanded the fix in PR #273.

What PR #273 now covers

The PR is no longer just a narrow summarizer tweak. The branch now has focused coverage for the meaningful model-calling surfaces involved in this bug family:

1. Compaction summarization (summaryModel / summaryProvider)
2. Delegated expansion overrides (expansionModel / expansionProvider)
3. Large-file summarization (largeFileSummaryModel / largeFileSummaryProvider)

Important implementation detail

After a deeper debugging pass, the right fix turned out to be:

• preserve the plugin bridge's existing credential resolution path (including the Codex OAuth helper path)
• do not bypass first-pass credential resolution for openai-codex
• only suppress the wrong direct retry path in src/summarize.ts for runtime-managed / OAuth-backed providers

That matters because the bridge already has explicit openai-codex OAuth handling via auth profiles / getOAuthApiKey(...). The problem was the summarizer retry semantics fighting with that contract, not the absence of an OAuth bridge path.

Current focused validation on the PR branch

Most recent focused run on the merged validation tree:

npm test -- test/transaction-mutex.test.ts test/engine.test.ts test/summarize.test.ts test/index-complete-model-auth.test.ts test/index-secret-ref-auth-profiles.test.ts test/index-complete-provider-config.test.ts test/lcm-expand-query-tool.test.ts

Result:

• 7 test files passed
• 195 tests passed

PR: #273

So from my side, #177 is still the most directly relevant tracking issue for the Codex OAuth summarizer/auth-resolution gap, and #273 is the concrete fix attempt.

[100yenadmin]

Verified. @jalehman #177 is still the correct issue to keep open until PR #273 merges / releases, but it’s no longer “mysterious” or “stale noise.” It is now an actively addressed issue with a validated fix branch.