Best possible solution:

Land the #76576 startup-plan fix with its regression tests, and either correctly repair #76598 in the same branch or split/remove the tool fallback and changelog claim.

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

Yes, from source inspection. Current main omits selected non-startup context-engine plugins from startup plugin ids, and the PR's #76598 path can still return a loaded-empty registry without reloading tool entries.

Is this the best way to solve the issue?

No as submitted. The context-engine startup seam is the narrow maintainable fix for #76576, but the bundled #76598 change must reload loaded-empty registries or be removed from this PR.

Full review comments:

• [P2] Reload loaded-empty tool registries — src/plugins/tools.ts:811
  The fallback still only runs when resolvePluginToolRegistry() returns undefined. In the [Bug]: Path-based plugin tools (origin "config") not exposed after 2026.5.2 #76598 state, a compatible channel or active registry can already contain the requested plugin id but have no scoped tool entries; this branch then only emits diagnostics and still exposes no tools while the changelog says path-based plugin tools are fixed. Trigger a reload when the returned registry lacks scoped tool entries, or split/remove the [Bug]: Path-based plugin tools (origin "config") not exposed after 2026.5.2 #76598 change.
  Confidence: 0.86

Overall correctness: patch is incorrect
Overall confidence: 0.86

Acceptance criteria:

• pnpm test src/plugins/tools.optional.test.ts src/plugins/channel-plugin-ids.test.ts src/plugins/effective-plugin-ids.test.ts src/agents/runtime-plugins.test.ts
• pnpm check:changed in Testbox before handoff

What I checked:

• Current startup filter misses context-engine slot plugins: On current main, shouldConsiderForGatewayStartup() accepts explicit startup activation and memory startup plugins only; a selected non-startup kind: "context-engine" plugin falls through before activation can include it. (src/plugins/gateway-startup-plugin-ids.ts:102, 2b82c05a7fb1)
• Agent runtime loads only startup snapshot plugin ids: Agent runtime reads snapshot.startup.pluginIds and passes them as onlyPluginIds, so an omitted context-engine plugin is not loaded before engine resolution. (src/agents/runtime-plugins.ts:39, 2b82c05a7fb1)
• Reported warning matches resolver behavior: If the configured non-default context engine id is not registered, resolveContextEngine() logs the fallback warning and resolves the legacy engine. (src/context-engine/registry.ts:519, 2b82c05a7fb1)
• PR adds the intended context-engine startup seam: The PR adds resolveContextEngineSlotStartupPluginId() and threads contextEngineSlotStartupPluginId into startup filtering, with regression cases for include/exclude/legacy/id normalization. (src/plugins/gateway-startup-plugin-ids.ts:99, 0db6c287c59c)
• Tool fallback still misses loaded-empty registries: The PR's new cold-load path is guarded by if (!registry), but current registry lookup can return a registry that contains the requested plugin id with no scoped tool entries; the PR then only appends diagnostics and returns no tools while the [Bug]: Path-based plugin tools (origin "config") not exposed after 2026.5.2 #76598 changelog says the bug is fixed. (src/plugins/tools.ts:811, 0db6c287c59c)
• Docs confirm the context-engine slot contract: The docs describe plugin engines being selected through plugins.slots.contextEngine and registered through api.registerContextEngine, which supports startup loading the selected plugin before resolution. Public docs: docs/concepts/context-engine.md. (docs/concepts/context-engine.md:42, 2b82c05a7fb1)

Likely related people:

• @steipete: Recent current-main work changed src/plugins/tools.ts, the same tool-registry resolution surface affected by the [Bug]: Path-based plugin tools (origin "config") not exposed after 2026.5.2 #76598 part of this PR; the timeline also shows maintainer force-pushes to this branch. (role: recent maintainer; confidence: high; commits: 5e9135f2e23d; files: src/plugins/tools.ts, src/plugins/tools.optional.test.ts)
• @amknight: Recent current-main startup-planning work touched gateway-startup-plugin-ids.ts, the file where the context-engine startup selection belongs. (role: adjacent owner; confidence: medium; commits: 8142e67d633d, 1e4098134aa8; files: src/plugins/gateway-startup-plugin-ids.ts, src/plugins/tools.ts)
• @vincentkoc: The startup snapshot/runtime-plugin loading layer and standalone/active registry helper files in current main trace to the cron startup-state repair commit. (role: introduced behavior; confidence: medium; commits: 310b1987e143; files: src/agents/runtime-plugins.ts, src/plugins/runtime/standalone-runtime-registry-loader.ts, src/plugins/active-runtime-registry.ts)
• @jalehman: Git history points to the original custom context-engine plugin support and later context-engine prompt-cache maintenance, adjacent to the selected-engine behavior fixed here. (role: feature origin; confidence: medium; commits: fee91fefceb4, a327b6750dbe; files: src/context-engine/registry.ts, docs/concepts/context-engine.md, docs/plugins/manifest.md)

Remaining risk / open question:

• The [Bug]: Path-based plugin tools (origin "config") not exposed after 2026.5.2 #76598 changelog entry would overstate the fix unless the branch reloads loaded-empty registries or removes that unrelated tools claim.
• Targeted tests still need to run after the repair because this review was read-only.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 2b82c05a7fb1.