Summary

• Problem: cloned runtime configs can miss the runtime snapshot identity fast path and force repeated full stable-stringify/SHA256 cache-key work while resolving plugin tool descriptors.
• Why it matters: in large Windows gateway configs, this blocks the event loop during reply startup and matches the core-plugin-tools stall pattern reported in [Bug]: After enabling the gateway, it keeps timing out and reconnecting repeatedly #75944.
• What changed: add a per-resolvePluginTools WeakMap memo for descriptor config cache keys and thread it through cached descriptor reads/writes.
• What did NOT change (scope boundary): no Feishu/Lark, MiniMax, WebSocket, provider routing, secrets snapshot cloning, or skill discovery behavior changed.

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

• Related [Bug]: After enabling the gateway, it keeps timing out and reconnecting repeatedly #75944
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: plugin descriptor cache keys called resolveRuntimeConfigCacheKey repeatedly for the same cloned config object. Clones returned from the active secrets runtime are semantically equivalent to the active runtime snapshot, but they do not satisfy the object-identity fast path in resolveRuntimeConfigCacheKey, so each descriptor key could re-stringify and hash the whole config.
• Missing detection / guardrail: descriptor cache-key tests covered correctness but not repeated expensive config-key resolution for the same object inside one tool-resolution pass.
• Contributing context: [Bug]: After enabling the gateway, it keeps timing out and reconnecting repeatedly #75944 logs show large core-plugin-tools stages and event-loop/cpu saturation on Windows. This patch targets that concrete hot path, not every later stage in the reporter's trace.

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/plugins/tool-descriptor-cache.test.ts
• Scenario the test should lock in: repeated descriptor cache keys for the same config object in one resolution pass resolve the expensive config cache key once, while distinct config objects remain distinct.
• Why this is the smallest reliable guardrail: it directly covers the hot helper that multiplies config hashing across plugin descriptors without needing live Feishu/MiniMax credentials.
• Existing test that already covers this (if any): none.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

Large gateway configs should spend far less synchronous CPU time during plugin tool descriptor setup, reducing reply-startup event-loop stalls and downstream WebSocket timeouts/reconnects for this path.

Diagram (if applicable)

Before:
resolvePluginTools -> descriptor key per plugin -> hash same cloned config repeatedly -> event loop blocked

After:
resolvePluginTools -> descriptor key per plugin -> reuse per-pass config key memo -> descriptor setup stays responsive

Security Impact (required)

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

Repro + Verification

Environment

• OS: macOS local development host; Windows 11 Parallels guest for live Windows proof
• Runtime/container: Node 24.14.1 locally; Node 24.15.0 in Windows guest
• Model/provider: N/A for focused hot-path repro
• Integration/channel (if any): N/A for focused hot-path repro
• Relevant config (redacted): synthetic large runtime config with plugin entries, matching the cloned-runtime-config cache-key shape from [Bug]: After enabling the gateway, it keeps timing out and reconnecting repeatedly #75944

Steps

1. Build a large runtime config and set it as the runtime snapshot.
2. Pass a structured clone of that config through plugin descriptor cache-key construction.
3. Compare current-main behavior without memoization against the patched per-resolution memo path.

Expected

• Same-object descriptor config keys should be resolved once per tool-resolution pass.
• Event-loop delay should drop sharply for cloned runtime configs.

Actual

• Current-main behavior repeatedly hashes the cloned config for every descriptor key config slot.
• Patched behavior reuses the memoized config key.

Evidence

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

Focused tests:

pnpm test src/plugins/tool-descriptor-cache.test.ts src/plugins/tools.optional.test.ts
# 2 files passed, 38 tests passed

Formatting:

pnpm exec oxfmt --check --threads=1 CHANGELOG.md src/plugins/tool-descriptor-cache.ts src/plugins/tools.ts src/plugins/tool-descriptor-cache.test.ts
# All matched files use the correct format.

macOS deterministic probe:

{"useMemo":false,"keys":50,"entries":10000,"workMs":4089.8,"timerDelayMs":4090.5}
{"useMemo":true,"keys":50,"entries":10000,"workMs":31.4,"timerDelayMs":34.4}

Windows 11 Parallels live before/after hot-path proof:

{"node":"v24.15.0","platform":"win32","arch":"arm64"}
{"label":"clone/current-main","useMemo":false,"entries":2000,"keys":50,"workMs":3441.6,"timerDelayMs":3442.9,"hashCalls":150}
{"label":"clone/patched-memo","useMemo":true,"entries":2000,"keys":50,"workMs":58.5,"timerDelayMs":58.7,"hashCalls":1}

Changed gate:

pnpm check:changed
# Passed in Blacksmith Testbox for lanes: core, coreTests, docs

Human Verification (required)

• Verified scenarios: focused plugin descriptor config-key memoization test; existing plugin optional-tool descriptor cache tests; macOS deterministic before/after probe; Windows 11 Parallels live before/after hot-path probe; Testbox changed gate.
• Edge cases checked: distinct config objects still produce distinct descriptor keys inside the same memo.
• What you did not verify: full end-to-end Feishu/Lark persistent connection plus MiniMax-M2.7 validation from [Bug]: After enabling the gateway, it keeps timing out and reconnecting repeatedly #75944. This PR validates the concrete core-plugin-tools cloned-config hashing hot path, not every symptom in the reporter's environment.

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
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: caching config keys too broadly could make descriptor keys stale if callers mutate config objects.
  • Mitigation: the memo is scoped to one resolvePluginTools pass, not global descriptor cache state.
• Risk: object-identity memoization could merge distinct configs accidentally.
  • Mitigation: the WeakMap is keyed by object identity; tests assert distinct objects remain distinct.