You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Insiders Feedback: Issue creation widget in VS Code Copilot Chat usability #2602
Feature: Issue creation widget in VS Code Copilot Chat
Feedback:
I love this feature. This is way better than looking at JSON.
Two issues:
When bypassing approvals, the widget still shows even though the agent creates the issue later on in the chat. This can lead to duplicate issue creation if you edit the text in the widget and submit it again, not realizing the agent has already auto-created the issue.
After submitting, I moved on to other work, then came back to a disconnected codespace. After reconnecting, the chat rendered with the widget as if I never submitted the new issue to be created, even though it was already created.
Screenshot: taken after reconnecting to codespace, showing the widget as if issue was never submitted (even though it was)
This is a very interesting point - some kind of persistent state on reloads would be fantastic. I'm thinking of ways that this could be ensured across different clients.
I hit a related duplicate-creation path through an MCP client:
Calling an interactive GitHub create tool opens a form; the tool response tells the caller to wait for the user to submit it.
After submission, the client can surface a new call_tool request with _ui_submitted: true instead of returning the result of the original invocation.
If the agent treats that as a request to call the create tool again, another form opens. Submitting both can create duplicate issues. I have hit this and created duplicate issues.
Expected: submitting the form should resolve the original pending tool call with its result, or submissions/retries should be correlated and idempotent so the agent cannot accidentally open a second create form.
Activity
mattdholloway commentedon Jun 16, 2026
This is a very interesting point - some kind of persistent state on reloads would be fantastic. I'm thinking of ways that this could be ensured across different clients.
Omzig commentedon Oct 22, 2026
I hit a related duplicate-creation path through an MCP client:
call_toolrequest with_ui_submitted: trueinstead of returning the result of the original invocation.Expected: submitting the form should resolve the original pending tool call with its result, or submissions/retries should be correlated and idempotent so the agent cannot accidentally open a second create form.