Problem
Agents send plans to the client via the plan session update: a list of
entries with content, priority and status. The client renders it read-only.
When the agent then asks to leave planning mode (e.g. ExitPlanMode in the
Claude adapter), the user's only choices are all-or-nothing: accept the plan
(in one of several permission modes) or keep planning.
In practice a plan is rarely entirely right or entirely wrong. Usually 8 of
10 steps are fine and 2 are unwanted. Today the user has to reject the whole
plan and restate their decisions in prose, which is slow and error-prone —
especially in IDE clients where the plan is already displayed as a structured
list the user is looking at.
Proposal
Let the client return a per-entry decision alongside the plan approval.
Sketch:
- Give each plan entry a stable
id in the plan session update.
- Extend the permission request that accompanies leaving plan mode so the
client may include a selection — e.g. the set of accepted entry ids, or a
per-entry accepted | rejected map.
- Make it optional and backward compatible: agents that don't advertise the
capability, and clients that don't send a selection, keep the current
all-or-nothing behaviour.
This is deliberately a selection mechanism, not an editing one. Letting the
client rewrite plan text would be a much larger change; simply dropping
entries covers most of the pain.
Why at the protocol level
Clients already have the plan as structured data, so the UI is cheap —
a checkbox per entry. What is missing is any way to send that selection
back. No client-side workaround can fix this.
Current workarounds
- Ask the agent to write the plan to a markdown file with
- [ ] items,
edit it in the IDE, then instruct the agent to execute the checked items.
- Ask for numbered steps and reply with the numbers to drop.
Both work but bypass the plan UI entirely, which suggests the built-in
plan view is missing something.
Environment
- Client: IntelliJ IDEA (ACP integration)
- Agent: @agentclientprotocol/claude-agent-acp
Problem
Agents send plans to the client via the
plansession update: a list ofentries with content, priority and status. The client renders it read-only.
When the agent then asks to leave planning mode (e.g.
ExitPlanModein theClaude adapter), the user's only choices are all-or-nothing: accept the plan
(in one of several permission modes) or keep planning.
In practice a plan is rarely entirely right or entirely wrong. Usually 8 of
10 steps are fine and 2 are unwanted. Today the user has to reject the whole
plan and restate their decisions in prose, which is slow and error-prone —
especially in IDE clients where the plan is already displayed as a structured
list the user is looking at.
Proposal
Let the client return a per-entry decision alongside the plan approval.
Sketch:
idin theplansession update.client may include a selection — e.g. the set of accepted entry ids, or a
per-entry
accepted | rejectedmap.capability, and clients that don't send a selection, keep the current
all-or-nothing behaviour.
This is deliberately a selection mechanism, not an editing one. Letting the
client rewrite plan text would be a much larger change; simply dropping
entries covers most of the pain.
Why at the protocol level
Clients already have the plan as structured data, so the UI is cheap —
a checkbox per entry. What is missing is any way to send that selection
back. No client-side workaround can fix this.
Current workarounds
- [ ]items,edit it in the IDE, then instruct the agent to execute the checked items.
Both work but bypass the plan UI entirely, which suggests the built-in
plan view is missing something.
Environment