Problem and result
Tool approval currently returns a boolean and a denied call receives a generic “not approved” result. When the user wants a smaller change or an offline test instead, the model must guess why it was refused or wait for another chat turn.
Add an optional bounded instruction when declining a specific tool call, for example “Use the offline unit suite.” Return it once as part of that call’s denial result so the current run can choose a better next step.
Acceptance checks
- Introduce a typed verdict containing approval/denial and optional denial feedback. Bind feedback to the original call ID and return it exactly once through the normal tool-result path on supported local and cloud host loops.
- Feedback cannot approve the call, trigger execution, dispatch a slash/shell command, reset the failure budget, or cause a denied operation to be retried automatically. Preserve argument and authority checks.
- Use a separate short-lived input buffer and lease for feedback. Bound its length and allow skipping/cancelling it; preserve the main draft, cursor, reviewed shell attachments, streaming input, and pending queue.
- Retain existing non-TTY decisions and automatic approval behavior. Do not invent feedback for
--yes or intercept PTY/password ownership. A declined call without a note retains a clear generic denial.
- Feedback is ephemeral turn data, not new prompt history, generic logs, or RC fields. Any explicit transcript/export behavior follows the existing sharing contract.
- Fixtures cover deny-with-note, deny-without-note, cancellation, concurrent queued input, duplicate call IDs/delivery, and local/hosted tool-result parity. Verify the denied executor never runs.
Landing boundary
This improves the interactive tool approval path. It does not duplicate remote-control structured verdict work in #302 or add persistent approval policies. Reuse the composer’s pure editing helpers under a distinct lease; do not add history search inside approval prompts.
Evidence and planning
Package: Run control and context. Priority: P2. Rough engineering estimate: 1–2 days, including focused fixtures; this is a planning estimate, not a measured benchmark.
Reviewed against v4.20.0 at 4f1717bc120917e1b04d0baa939855417ef866a4: src/core/tool_approval.ts, src/commands/code.ts, src/commands/chat.ts, test/tool_approval.test.ts.
Comparator: Claude Code permission prompts support answering with a comment. Aether can make a refused tool result equally actionable without expanding its authority.
Created from the LOOP-19 review of the README, all 23 open issues, four open PRs, and recent shipped work on 2026-10-09. These are proposed changes; the acceptance checks below have not been executed.
Problem and result
Tool approval currently returns a boolean and a denied call receives a generic “not approved” result. When the user wants a smaller change or an offline test instead, the model must guess why it was refused or wait for another chat turn.
Add an optional bounded instruction when declining a specific tool call, for example “Use the offline unit suite.” Return it once as part of that call’s denial result so the current run can choose a better next step.
Acceptance checks
--yesor intercept PTY/password ownership. A declined call without a note retains a clear generic denial.Landing boundary
This improves the interactive tool approval path. It does not duplicate remote-control structured verdict work in #302 or add persistent approval policies. Reuse the composer’s pure editing helpers under a distinct lease; do not add history search inside approval prompts.
Evidence and planning
Package: Run control and context. Priority: P2. Rough engineering estimate: 1–2 days, including focused fixtures; this is a planning estimate, not a measured benchmark.
Reviewed against v4.20.0 at
4f1717bc120917e1b04d0baa939855417ef866a4: src/core/tool_approval.ts, src/commands/code.ts, src/commands/chat.ts, test/tool_approval.test.ts.Comparator: Claude Code permission prompts support answering with a comment. Aether can make a refused tool result equally actionable without expanding its authority.
Created from the LOOP-19 review of the README, all 23 open issues, four open PRs, and recent shipped work on 2026-10-09. These are proposed changes; the acceptance checks below have not been executed.