Spurious "Unknown tool name" warning when a cross-family sub-agent inherits the parent tool list

Describe the bug

Spawning a cross-model-family sub-agent re-validates the parent session's tool allowlist/excludedlist against the sub-agent's tool registry. Because apply_patch is registered only for OpenAI Codex models, a valid Codex-session config emits a spurious warning the moment a Claude sub-agent starts:

Unknown tool name in the tool excludedlist: "apply_patch"

The name is not unknown — apply_patch is a first-class CLI tool ("Add apply_patch toolchain for OpenAI Codex models", per the changelog). It is simply not in the Claude registry. The message misreports a legitimate cross-family situation as a config typo.

This surfaces most often with rubber-duck, because its complementary model strategy deliberately selects the opposite model family, making it by far the most common cross-family spawn in normal use.

Steps to reproduce

copilot -p "Use the task tool with agent_type='rubber-duck' and model='claude-opus-5' asking it to reply PING." \
  --model gpt-5.3-codex \
  --excluded-tools apply_patch \
  --allow-all-tools

The parent (gpt-5.3-codex) accepts apply_patch silently. The warning appears only when the Claude sub-agent spawns.

Isolating the trigger

Controlled 2×2 — identical parent model and identical flags, varying only the sub-agent:

Sub-agent spawned	Warning
none	0
gpt-5.3-codex (same family)	0
claude-opus-5 (cross-family)	1 (reproduced on 2/2 runs)

The cross-family spawn is the sole variable. Same behaviour via --available-tools (reported as tool allowlist instead of tool excludedlist).

Model-family dependence of the registry, confirmed independently:

Command	Result
--available-tools apply_patch --model claude-opus-5	warns
--available-tools apply_patch --model gpt-5.3-codex	silent

Expected behaviour

A tool name that is valid for some model family should not be reported as unknown. Either:

1. Validate against the union of all model families' registries, warning only for names unknown everywhere (genuine typos); then silently filter per-family at spawn time; or
2. If a per-family notice is genuinely wanted, word it accurately — e.g. Tool "apply_patch" is not available for claude-opus-4.5; excluded from sub-agent — rather than "Unknown tool name".

Actual behaviour

The user is warned about a consequence of a decision the CLI made on its own (rubber-duck selecting a complementary model). The warning is unactionable: removing apply_patch defeats the intent for the Codex parent, and keeping it emits the warning on every session that spawns a cross-family sub-agent.

Root cause

The emitter is sessionPlanToolFilterDiagnosticsForSessionJson in prebuilds/darwin-arm64/runtime.node. Calling it directly reproduces the exact strings:

const h = require("./prebuilds/darwin-arm64/runtime.node");
const f = h.sessionPlanToolFilterDiagnosticsForSessionJson;

f("sess", JSON.stringify({ availableTools: ["apply_patch"] }));
// -> Unknown tool name in the tool allowlist: "apply_patch"

f("sess", JSON.stringify({ excludedTools: ["apply_patch"] }));
// -> Unknown tool name in the tool excludedlist: "apply_patch"

The configured list is checked against the session's registered tool names, with no awareness that the registry varies by model family. Warnings dedupe per name per session via warnedUnknownTools / markWarned.

Impact

Cosmetic. The tool list is still applied correctly and nothing breaks — but the message is misleading, unactionable, and appears in the common rubber-duck path, which trains users to ignore configuration warnings.

Related

Same weak spot as #4432 (cross-family sub-agent handling), though distinct: #4432 is functional (the wrong model actually runs), this one is presentational.

Environment

• Copilot CLI 1.0.79, darwin-arm64 (macOS, Apple Silicon)
• Reproduced with parent gpt-5.3-codex, sub-agent claude-opus-5

Inizia con sessionPlanToolFilterDiagnosticsForSessionJson in prebuilds/darwin-arm64/runtime.node e riproduci i casi di allowlist ed excludedlist dell’issue usando sub-agent tra famiglie. Traccia come vengono selezionati i registri degli strumenti e come vengono usati warnedUnknownTools/markWarned. Il lavoro è completo quando gli strumenti validi di un’altra famiglia di modelli non producono più un avviso “Unknown tool name”, mentre i nomi sconosciuti ovunque continuano a produrlo.