Cancelling/closing an ask_user form silently discards all previously answered fields

Offen

#4,945 erstellt am 22.9.2026 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 3/5
Geschätzter Aufwand: 1-2 Tage
Anfängerfreundlichkeit: 65/100

Issue-Typ: Bug
Klarheit: Klar beschrieben
Aktivitätsstatus: Aktiv
Tech-Stack: shell
Bereich: cli, developer-experience

Rechercherichtung

Look for the ask_user/elicitation tool implementation in the codebase, likely in a directory like src/ or lib/. Find where form cancellation is handled and where field answers are stored. Examine the flow that returns 'User cancelled the request' and see if partial answers can be captured. Check for UI components that manage form state. Testing involves running the CLI and triggering a multi-field form to verify the bug and any fix.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

area:tools

Describe the bug
When a multi-field form (via the ask_user/elicitation tool) is cancelled or closed (e.g. via Esc, see related issue about Esc behavior), any fields the user had already answered before cancelling are discarded entirely. The tool result returned to the agent is just a generic cancellation notice with no partial data — even though the user may have already provided a real, considered answer to an earlier question in the same form.

Expected behavior
If a user has answered one or more fields before a form is exited/cancelled, those partial answers should either be (a) preserved and returned to the calling agent so context isn't lost, or (b) the UI should clearly warn the user before discarding a partially-completed form, distinguishing 'cancel with no answers yet' from 'cancel after already answering something.'

Additional context
In a real session, a user answered the first question of a multi-field form, then the form was closed (likely via Esc). The tool call result contained only "User cancelled the request" with no indication that a field had been answered, and no way to recover it. The agent could not tell the user what had been captured (nothing) or distinguish intentional full-cancellation from an accidental exit after partial input.

Vorherrschende Sprache: Shell
Sterne: 11.2k
Forks: 1.9k
Ø Merge: 14 Std. 16 Min.
Gemergte PRs (30 T.): 6

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus github/copilot-cli

Built-in skill `github-pr-media` cannot run: `gh auth token` is empty in a cloud agent session, and the endpoint rejects `Bearer` Offen

triage

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100

github/copilot-cli#4932 · Erstellt am 22.9.2026
/ide finds no workspaces under the CLI sandbox: kill(pid,0) EPERM misread as a dead process Offen

triage

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100

github/copilot-cli#4909 · Erstellt am 19.9.2026
MCP OAuth: DCR sends client_name "copilot-cli", rejected with 403 by Figma's allowlist (expects "GitHub Copilot CLI") Offen

triage

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100

github/copilot-cli#4906 · Erstellt am 18.9.2026
/feedback: “Save feedback bundle” is easily mistaken for submitting feedback Offen

triage

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100

github/copilot-cli#4848 · Erstellt am 15.9.2026
Built-in research agent tells subagents to call unavailable github/get_me tool Offen

area:agents area:mcp

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100

github/copilot-cli#4729 · Erstellt am 04.9.2026

Alle Issues in github/copilot-cli