Cancelling/closing an ask_user form silently discards all previously answered fields
還沒有人認領這個 Issue。
評估
- 難度
- 3/5
- 預估耗時
- 1-2 天
- 新手友好度
- 65/100
- Issue 類型
- 缺陷
- 描述清晰度
- 描述清楚
- 活躍度
- 活躍
- 技術堆疊
- shell
研究方向
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.
由索引模型根據 Issue 內容生成。
描述
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.
- 主要語言
- Shell
- 星號
- 11.2k
- 分支
- 1.9k
- 平均合併
- 14 小時 16 分鐘
- 30 天內合併 PR
- 6
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
github/copilot-cli 的其他 Issue
-
triage
難度 2/5 1-3 小時 新手友好度 75/100
github/copilot-cli#4932 ·
-
triage
難度 2/5 1-3 小時 新手友好度 78/100
github/copilot-cli#4909 ·
-
triage
難度 2/5 1-3 小時 新手友好度 76/100
github/copilot-cli#4906 ·
-
triage
難度 2/5 1-3 小時 新手友好度 72/100
github/copilot-cli#4848 ·
-
area:agents area:mcp
難度 2/5 1-3 小時 新手友好度 72/100
github/copilot-cli#4729 ·
查看 github/copilot-cli 的全部 Issue
相似的 Issue
-
good-start
難度 2/5 1-3 小時 新手友好度 65/100
-
難度 2/5 1-3 小時 新手友好度 70/100
-
難度 2/5 1-3 小時 新手友好度 75/100
VilnaCRM-Org/user-service#497 ·
-
難度 2/5 1-3 小時 新手友好度 75/100
conda-forge/spacy-feedstock#177 ·
-
area:jail bug security severity:low track:open-source
難度 1/5 1 小時以內 新手友好度 75/100