Regression in v1.0.60: userPromptSubmitted hook additionalContext no longer injected into planner (worked in v1.0.59)

[Harihara04sudhan]

Regression boundary

	v1.0.59 (working)	v1.0.60 (broken)
Release date	2026-06-02	2026-06-05 16:42 UTC
Our last working session	2026-06-05 16:11 UTC (31 min before v1.0.60 shipped)	every session since

Same machine, same plugin, same prompts. Hook behavior changed between these two versions.

What changed

userPromptSubmitted hooks loaded from a plugin's hooks.json continue to be discovered (Copilot's startup banner shows Loading: 8 hooks, 3 skills, 1 MCP server, 1 plugin), but the hookSpecificOutput.additionalContext we return from the hook is no longer being injected into Copilot's planner.

In v1.0.59 the planner consumed the additionalContext directive and acted on it (calling the MCP tool we requested). In v1.0.60 the directive is silently dropped.

Plugin under test

armoriq/armorCopilot — public, MIT.

Plugin's userPromptSubmitted hook returns:

{
  "hookSpecificOutput": {
    "hookEventName": "UserPromptSubmit",
    "additionalContext": "ArmorCopilot active. Call `register_intent_plan` first; step `action` = tool name, `metadata.inputs` = `{}` matches by name only.\\n\\nFor policy changes call `policy_update` (mode: replace rewrites the full ruleset; empty rules clears policy)."
  }
}

Verified by piping a sample payload to the hook script manually — it emits this output correctly on both versions.

Reproduction (3 prompts)

copilot plugin marketplace add armoriq/armorCopilot
copilot plugin install armorcopilot@armoriq
copilot
> show me current armorcopilot policies
> set a policy to block all web fetches
> show me the updated policies

Expected (v1.0.59): each prompt triggers register_intent_plan MCP tool call (because the additionalContext directive tells Copilot to). Confirmed by stderr from the plugin's MCP server in ~/.copilot/logs/:

2026-06-05T16:13:51 [stderr] Capturing plan: llm=github-copilot, prompt=Show active security rules
2026-06-05T16:14:10 [stderr] Capturing plan: llm=github-copilot, prompt=Block all web fetches
2026-06-05T16:15:12 [stderr] Capturing plan: llm=github-copilot, prompt=Show active security rules

Observed (v1.0.60): register_intent_plan fires only on the first prompt of a new session (when Copilot does MCP tool discovery anyway). Subsequent prompts get no plan registration. Today's MCP stderr from the same machine shows a single Capturing plan entry per session, regardless of how many user messages.

What still works on v1.0.60

• Plugin discovery (Loading: 8 hooks, ... banner)
• MCP server registration + tool calls (register_intent_plan, policy_read, policy_update all callable when Copilot decides to)
• Hook script execution itself — invoking it manually with the documented payload returns the right JSON

What's broken

Just one thing: Copilot's planner stopped consuming additionalContext from userPromptSubmitted hooks. Everything else is fine.

Workaround attempted

Downgrading via npm doesn't work — Copilot CLI's --version reports a runtime-fetched version that's independent of the installed npm package. Installing @github/copilot@1.0.59 and @github/copilot-darwin-arm64@1.0.59 still produces a binary that reports 1.0.60 and exhibits the broken behavior.

Related

• Plugin-defined preToolUse hooks (hooks.json) do not fire - neither in main session nor subagents #2540 — broader issue about plugin hooks not firing in some configurations. This is a more specific regression in the same area.

Environment

• Copilot CLI: 1.0.60 (last working: 1.0.59)
• OS: macOS 25.5.0
• Shell: zsh
• Node: v25.8.1
• Plugin install source: marketplace armoriq/armorCopilot

[Harihara04sudhan]

Update: still reproducing on v1.0.61 (published 2026-06-09 22:02 UTC, ~2h after this issue was filed). The v1.0.61 release notes touched two hook-related items but both are UI-only (/env output formatting and "Hook progress status lines marked as temporary"). The userPromptSubmitted.hookSpecificOutput.additionalContext injection path is not in the changelog and the regression is unchanged.

Same repro on v1.0.61

Two user prompts in a single session:

1. show me current armorcopilot policies
2. read README.md and tell me what this project does

Expected (matched v1.0.59 behavior): each prompt triggers register_intent_plan MCP call because our userPromptSubmitted hook returns {"hookSpecificOutput":{"additionalContext":"Call register_intent_plan first..."}}.

Observed on v1.0.61: plan registration fires only on the first prompt.

$ grep -c 'Capturing plan' ~/.copilot/logs/process-1781090406635-32550.log
1

(MCP server's stderr appears once, not twice as it did on v1.0.59.)

Our hook script still emits the correct JSON when fired manually — verified by piping a representative payload to node bootstrap.mjs router — so the bug is on Copilot's side consuming additionalContext, not on our side producing it.

Happy to provide a full debug-level log if it'd help bisect between v1.0.59 and v1.0.60.

[Harihara04sudhan]

Sharper characterization — the regression isn't "additionalContext is dropped entirely," it's "additionalContext is only honored when the planner already decides to call plugin MCP tools."

Same session on v1.0.61, three prompts in order:

#	Prompt	Tools planner picked	register_intent_plan (MCP) fired?
1	read README.md and tell me what this project does	glob, read (built-in)	❌ no
2	show me current armorcopilot policies	policy_read (plugin MCP)	✅ yes
3	block web fetch add policy	policy_update (plugin MCP)	✅ yes

Confirmed by log: only 2 "Capturing plan" stderr entries in ~/.copilot/logs/process-*.log for 3 user prompts.

In v1.0.59 all 3 prompts would have triggered register_intent_plan because the planner consumed the additionalContext directive ("Call register_intent_plan first") universally, regardless of what tools the prompt naturally needed.

Why this shape of regression is the worst case

For a security-enforcement plugin like ArmorCopilot, the prompts that SHOULD trigger plan registration most reliably are exactly the ones that DON'T anymore:

• Plain read, edit, bash, web_fetch prompts — the actual security surface — now skip the hook directive
• Only meta-prompts that already touch the plugin's own MCP tools still get the directive honored

So the plugin can still demo policy management, but the auto-enforcement on raw tool calls is silently disabled for any prompt that doesn't happen to mention the plugin.

Likely root cause guess

It looks like Copilot's planner is now treating additionalContext as a tool-availability hint rather than an unconditional system-prompt prefix. If the planner decides "this prompt doesn't need plugin tools," it skips the directive entirely.

Fix would be to feed additionalContext into the system/system-augmentation prompt before tool-availability decisions are made, not after.

Workaround we're attempting on our side

In the meantime, we may try advertising register_intent_plan in our MCP server's tool description with stronger "MUST CALL FIRST" framing, in the hope that the planner discovers it via MCP-tool list and invokes it as its first action regardless of context. Will report back if that survives the regression.

[Harihara04sudhan]

Test matrix locked in on v1.0.61 — confirms the bug shape exactly.

Same machine, fresh copilot session, 5 prompts in order:

#	Prompt	Built-in tools used	MCP tools used	register_intent_plan fired?
1	list files in this directory	glob	—	❌
2	search for the word "ArmorIQ" in any file here	grep	—	❌
3	create a file called test.txt with the content "hello"	write	—	❌
4	show me current armorcopilot policies	—	policy_read	✅
5	block web fetch add policy	—	policy_update	✅

Confirmed by the MCP server's stderr log:

$ grep -c 'Capturing plan' ~/.copilot/logs/process-1781090406635-32550.log
3

$ grep 'Capturing plan' ~/.copilot/logs/process-1781090406635-32550.log
Capturing plan: prompt=Read the current ArmorCopilot policy state...
Capturing plan: prompt=Read the current ArmorCopilot policy state...
Capturing plan: prompt=Add a deny policy for web fetch calls

3 register_intent_plan invocations for 5 prompts. The 3 that fired are all MCP-tool prompts. The 3 that didn't (list / grep / write) are all built-in-tool-only prompts.

Pattern is binary

It's not probabilistic — the directive is consumed iff the planner already decides the prompt needs a plugin's MCP tools. Built-in-only prompts deterministically skip the directive.

Severity recap

For ArmorCopilot specifically this means automatic enforcement is silently disabled on the tools we most need to gate (bash, read, write, edit, web_fetch). Customers running the plugin in v1.0.60+ get a false sense of security — they see "ArmorCopilot is active" at session start but most tool calls bypass the registered-plan check.

We're rolling out a workaround on our side (strong "MUST CALL FIRST" framing in our register_intent_plan MCP tool description) to see if the planner-level MCP discovery can be coerced into calling it on every prompt regardless of the directive. Will report results.