Summary
applyManagerApiKeyFallback gates credential inheritance on parentProvider === providerForModel(childModel). parentProvider is derived from parentModel in the SubagentManager ctor. When a forkSubagent/child-manager caller omits parentModel, the gate degrades to key-shape inference: a non-sk-ant parent key (a bare sk- OpenAI key, or a local Anthropic-shim key) yields effectiveParent = undefined and inherits unconditionally — so the reverse-direction (openai→anthropic) leak protection added by #374/#377 is off for that fork.
Evidence
src/agent/tools/child-credential.ts:91-104 — provider-identity gatesrc/agent/tools/child-credential.ts:100-102 — key-shape fallback when parentProvider is absentsrc/agent/subagent.ts:301-302 — parentProvider derived from parentModel
Why it matters
Narrow but real: the recent credential-leak fixes (#374, #377, #378) implicitly assume parentModel is always threaded. Any fork call site that omits it silently loses the reverse-leak guard.
Proposed direction
- Audit every
forkSubagent / child-manager construction site to confirm parentModel is always passed.
- Consider making
parentModel required on the manager, or hardening the fallback to fail closed (no inherit) when provider identity is unknown, rather than inheriting on key-shape.
Severity: LOW–MED. Ref #378, #374, #377.
Found via a read-only tool/subagent/worktree audit. (Caveat: I did not exhaustively enumerate every call site to confirm whether the omission actually occurs in practice — the gap is in the fallback logic; the audit item is to verify no live caller hits it.)
Summary
applyManagerApiKeyFallbackgates credential inheritance onparentProvider === providerForModel(childModel).parentProvideris derived fromparentModelin theSubagentManagerctor. When aforkSubagent/child-manager caller omitsparentModel, the gate degrades to key-shape inference: a non-sk-antparent key (a baresk-OpenAI key, or a local Anthropic-shim key) yieldseffectiveParent = undefinedand inherits unconditionally — so the reverse-direction (openai→anthropic) leak protection added by #374/#377 is off for that fork.Evidence
src/agent/tools/child-credential.ts:91-104— provider-identity gatesrc/agent/tools/child-credential.ts:100-102— key-shape fallback whenparentProvideris absentsrc/agent/subagent.ts:301-302—parentProviderderived fromparentModelWhy it matters
Narrow but real: the recent credential-leak fixes (#374, #377, #378) implicitly assume
parentModelis always threaded. Any fork call site that omits it silently loses the reverse-leak guard.Proposed direction
forkSubagent/ child-manager construction site to confirmparentModelis always passed.parentModelrequired on the manager, or hardening the fallback to fail closed (no inherit) when provider identity is unknown, rather than inheriting on key-shape.Severity: LOW–MED. Ref #378, #374, #377.
Found via a read-only tool/subagent/worktree audit. (Caveat: I did not exhaustively enumerate every call site to confirm whether the omission actually occurs in practice — the gap is in the fallback logic; the audit item is to verify no live caller hits it.)