[BUG] pi: sessionManager.buildContextEntries() removed in omp 18.x - extension throws every turn and the anthropic provider never registers

[tomolom]

Describe the bug

On Pi/omp, the extension throws on every turn_start:

Extension "C:\Users\<user>\.omp\plugins\node_modules\@cortexkit\pi-anthropic-auth\dist\index.js" error:
 ctx.sessionManager.buildContextEntries is not a function. (In 'ctx.sessionManager.buildContextEntries()',
 'ctx.sessionManager.buildContextEntries' is undefined)

Because the handler throws before the provider override takes effect, the anthropic provider is never registered. omp then falls back to its built-in anthropic provider, which finds no credential:

error: No API key found for anthropic.
Use /login, set an API key environment variable, or create C:\Users\<user>\.omp\agent\agent.db

The user-visible symptom is misleading: every modelRoles entry pointing at anthropic/* silently drops out, the session pins to whatever other provider is authenticated (moonshot/kimi here), and the model cycler reports only one role defined. It looks like an auth/login problem, but the credentials are valid the whole time.

The call site is in the turn_start handler of dist/index.js:

const transitions = collectPiEffortHistory(
  ctx.sessionManager.buildContextEntries(),
  ctx.sessionManager.getBranch()
);

sessionManager.buildContextEntries() does not exist in @oh-my-pi/pi-coding-agent 18.1.13. Auditing every sessionManager.* call in the installed package against the host bundle:

call	present in omp 18.1.13
getBranch	yes
getSessionId	yes
buildContextEntries	no

So this is the only break. The host's equivalent accessor is getEntries(), which omp uses internally in the same way (this.sessionManager.getEntries()).

This looks like package-name drift: package.json still declares

"peerDependencies": {
  "@earendil-works/pi-ai": "*",
  "@earendil-works/pi-coding-agent": "*",
  "@earendil-works/pi-tui": "*"
}

i.e. the legacy Pi packages, while omp ships @oh-my-pi/pi-coding-agent. With * ranges nothing catches the removed method at install time.

To Reproduce
Steps to reproduce the behavior:

1. Install omp 18.1.13 — bun install -g @oh-my-pi/pi-coding-agent
2. Install the package — omp plugin install @cortexkit/pi-anthropic-auth (1.22.0)
3. Have a valid Claude OAuth credential available (here: sidecar main: { type: "opencode", provider: "anthropic" })
4. Run any turn — omp -p --no-session --model anthropic/claude-haiku-4-5 "Reply with exactly: OK"
5. See the extension error above, then error: No API key found for anthropic

Expected behavior

The turn_start effort-history hook should resolve session entries through an accessor that exists on the current host, and a failure inside this optional Fable-5.1 effort-tracking hook should not prevent the anthropic provider override from registering. A hook that only feeds mid-conversation effort markers should degrade to "no transitions" rather than disabling authentication for the whole provider.

Screenshots

N/A — terminal output included above.

Desktop (please complete the following information):

• OS: Windows 11 (win32 x64)
• Browser: N/A — CLI (omp/Pi, not the OpenCode TUI)
• Version: @cortexkit/pi-anthropic-auth 1.22.0, @cortexkit/anthropic-auth-core 1.22.0, @oh-my-pi/pi-coding-agent 18.1.13, Bun 1.4.0

Smartphone (please complete the following information):

N/A

Additional context

Locally patching the single call site to fall back to getEntries() fully resolves it — the provider registers and the stored credential is picked up with no login step:

collectPiEffortHistory(
  (ctx.sessionManager.buildContextEntries?.() ?? ctx.sessionManager.getEntries()),
  ctx.sessionManager.getBranch()
);

Verified after patching:

omp -p --no-session --model anthropic/claude-haiku-4-5 "Reply with exactly: OK"  -> OK
omp models   ->   anthropic (25)   moonshot (17)   openai-codex (7)

Before the patch omp models listed only moonshot (17).

The optional-call form keeps it working against older hosts that still expose buildContextEntries.

Possibly related, same class of legacy-API drift (reported separately only because I could not confirm it independently): on omp 18.x the package also appears to expect createAssistantMessageEventStream / a value export of AssistantMessageEventStream from the pi-ai package root, which omp's legacy-pi-ai-shim.ts exposes only as a type. I have a local shim for that too, but patching it alone did not fix the error above — buildContextEntries was the actual blocker.