GitHub Copilot App Feedback

Post your feedback on the GitHub Copilot App as a comment below — or use the /feedback slash command in the comment box to auto-fill the template. Don't overthink it — we want your gut reactions!

If comfortable, please record yourself launching the app for the first time [optional]. Feel free to answer the questions below in your recording by talking out loud rather than writing it down – no need to repeat your answers if you've already answered them verbally. You may attach your video to the discussion comment, or provide a link to a video.

You've had a few days with the app now. We'd love to hear how things have evolved.

Again, please feel free to share recordings of specific, real workflows that involve the GitHub Copilot App. Talk out loud and feel free to answer the questions below verbally in the video or through written answers.

1. What have you tried doing with the app so far (e.g., start a new project, review a PR, write code, etc.), and why?

2. What has been most useful about this app? What tasks is it particularly suited for?

3. How does this experience compare to other tools you use today (e.g., Copilot in your IDE, Claude Code, Codex)? What does the GitHub App do better or worse?

4. What is missing, or confusing, if anything?

5. What type of tasks do you still feel like you need to go to github.com or other tools for?

6. If you had a magic wand to make this app just right for you, what would you change?

[jessejlt]

Windows + WSL support is limited. Otherwise, really like the direction of this project.

[albertored]

Not only WIndows + WSL but in general it would be very useful to a feature similar to vscode remote SSH.
Ideally it should be possible to open repositories remotely so that agent can run commands and use skills directly on the target machine without the need of installing the tooling on the Windows (or whatever else) host

[joshuameng]

I am unable to login after installing on Windows. I click "Sign in to GitHub". The application states "Opening GitHub.com to authorize..." and provides an 8 digit code. The web browser never opens, so I navigate manually to https://github.com/login/device/ to enter the code. After submitting the code I get the message "Uh oh, we couldn't find anything Please make sure you entered the user code correctly."

[codess-aus]

Tried to install it, but it's not trusted. Have reported it as safe, but as I'm not the owner they might not believe me

[dgibson66]

I pulled the Appimage to one of our RHEL8.8 systems with no luck. Can you build on as old a system as possible so that those of us in the corporate space have a prayer of running it without having to go virtual?

ETA: Yes I know that there are dinosaurs younger than RHEL8.8 but still, at least sharing what the system requirements are would help.

[SlothCroissant]

Need the ability to have the "commit" button use a custom commit message syntax with a given model - much like VSCode provides: https://code.visualstudio.com/docs/sourcecontrol/staging-commits. Bonus points if you can select the model and provide specific instructions for commit messages.

Having to leave the GitHub App just to commit and push changes seems a bit silly. Alternative is to just have my instructions set to commit changes, but then at that point, the button is useless :)

[SlothCroissant]

With this UI, it really takes Copilot CLI to the next level, IMO (beyond the CLI, as it were :)

Idea that could be exceedingly useful in many enterprises - support UI navigation of GitHub Copilot marketplaces (https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/plugins-marketplace)

Keeping the marketplace experience inside one cohesive UI would be brilliant - install plugins, skills, agents, etc - all without leaving the app.

[cquanu]

Any plans to support transcribing or dictation?

[cquanu]

How can we edit our message just like in VS Code GHC agent.

[cquanu]

Chat mode: the PR status icon is wrong. It returned a list of "open PRs/color" that were already merged.

[jcleigh]

Please add automated workflows running on Copilot Cloud Agent instead of only locally

[cyonix]

I'd like to see the Chat Debug View feature ported here as well.

[AnushPadmanabhan]

It is awesome that we can have our team-specific custom workflow as a template here. We were in the verge of building something similar for the entire org. Super cool, we can improve on this.

[trollfalgar]

The browser don´t allow us to open different domains. For exemple, .test domains cannot be open. Forcing us to use localhost:port.

[Liebeck]

First of all. Thank you very much!

1. What have you tried doing with the app so far (e.g., start a new project, review a PR, write code, etc.), and why?

I have used three sessions for maintenance tasks on an existing project. For more details, see my newsletter post https://www.linkedin.com/pulse/episode-7-first-look-new-github-copilot-app-dr-matthias-liebeck-yniue

2. What has been most useful about this app? What tasks is it particularly suited for?

Very smooth UI experience. I love switching between the sessions, the progress indicator and the sound. I'm not sure if you prioritized my sessions since they were through the App, but they felt very very fast, like 5x from what I'm used to.

3. How does this experience compare to other tools you use today (e.g., Copilot in your IDE, Claude Code, Codex)? What does the GitHub App do better or worse?

The UI was very smooth. Still in early stages, but I can see myself switch to the GitHub Copilot App as main development environment for agentic coding in the next couple of months, if the issues from point 4 (see blow) are addressed.

4. What is missing, or confusing, if anything?

The most confusing what the Git commit behaviour. At first, I only managed to get automatic commits working, #419. Then, I guess I can't find a commit button or a way to specify a commit message #423

Maybe it's already there, but confusing since I can't find it.

#421
#422

5. What type of tasks do you still feel like you need to go to github.com or other tools for?

Right now, manual commits feel like I need to switch out of the GitHub App into a Git UI like Fork.

I'm also not sure how to use multiple sessions that from my local docker test setup in parallel. Usually, I would run my full E2E PlayWright test suite, but I have no idea how I would have three sessions that access the same docker container or at least something like "okay I need to access containers that session A uses. I wait until session A is done to spin up my own containers".

6. If you had a magic wand to make this app just right for you, what would you change?

See 4)

[AaronRobinsonMSFT]

I've got some feedback and a question from the Bing team.

I switched from copilot cli to the copilot app since you left. it's pretty crazy I feel like there's no reason to use the CLI anymore after using it exclusively for development the last couple of months.

Yay!

Is the copilot app using the same SDK as the CLI?

This is the question I'm trying to answer. I assume yes?

Where is the best place to talk directly with the team? I've got dual access and have access to Slack.

[chinkeongang]

I would to request "Subagent Configuration" features same as GitHub Copilot CLI "/subagents" command. The use case is keep the orchestration LLM model as frontier model on cloud API while host saving happen at subagent model being swap to local run LLM models for exploration task, code-review and other one-shot summary task. The objective is to save token cost by having hybrid of API and local hosted models working together. GitHub Copilot App already supports Model Providers but currently only being used in Chat session as the main orchestration model and there is no GUI interface in the settings section to further customize Subagent model to select a different models.

[Jess02]

Title: Feature Request: Allow selecting shell type (cmd, bash, Git Bash) instead of only PowerShell

Description:

In corporate environments, PowerShell may be disabled via Group Policy (GPO), EDR agents, or AppLocker restrictions, while cmd.exe or Git Bash remain available. Currently, the Copilot Desktop agent only supports executing commands through a PowerShell tool. When PowerShell is blocked, the agent loses ALL command execution capabilities — it cannot run git, mvn, npm, or any CLI tool.

Impact:

Cannot commit or push changes
Cannot run builds or tests
Cannot create PRs via gh CLI
Cannot verify file system state
The agent is reduced to file editing only
Suggested improvement:
Allow users to configure the shell backend (PowerShell, cmd.exe, bash, Git Bash, WSL) in Copilot Desktop settings. A fallback chain would also help (e.g., try PowerShell → cmd → Git Bash).

Environment:

OS: Windows (corporate managed)
Tool: Copilot Desktop App (CLI agent)
PowerShell: Disabled by corporate policy
cmd.exe: Available
Git Bash: Available
Workaround:
User must manually execute all commands in the terminal canvas panel, which defeats the purpose of autonomous agent operation.

[kjingers]

Feature Request: Ability to Restart / Re-enable MCP servers / tools in a running session

I notice for sessions I keep open for a while the MCP tools go away (which is expected). Is there a way to restart the MCP servers / tools in a session in the GHCP app? I found I can summarize + create a new session, which starts the mcps and tools in a fresh session. But was wondering if there was a good way to restart the tools in the same conversation? Or a better way to manage that?

I know /mcp exists for the CLI. And in VSCode - we are able to disable+reenable MCP servers and tools. But I'm not sure the best way in GHCP app.

I've tried quitting and restarting the GHCP, (which apparently does a restart_session, which should restart MCP servers), but this does not work for me. I think that may have worked once - but not consistently.

[travkin79]

I like working with GitHub Copilot Desktop App. It has a pleasant UI (with dark mode) and a good GitHub integration (in contrast to Claude Desktop App). I prefer using the GH Copilot Desktop App as a separate client in its own window (placeable on a second screen) with a uniform UI/UX, rather than using different IDE integrations across VSCode, IntelliJ IDEA, and Eclipse, each with its own UI and capabilities.

• GH Copilot Desktop App offers a great overview of the open sessions, grouped by git repos and a separate chat group.
• The review panel is very helpful to check the plan or suggested changes.
• Copilot CLI sessions can optionally be shown in GH Copilot Desktop App, that's useful, too.

Improvement ideas

• Context size not visible: The card with the input field, and several other session status details, lack details about the context. Hovering on the circle icon near the send button should not only show the session's AI credits and the consumed percentage of the plan, but also context size and other token consumption-related details. It's tedious to call /context command repeatedly. In addition, there should be some additional visualization of the context window size in percent near the plan consumption circle.
• Missing diagram/image support: The rendered conversation is not able to present diagrams or images (in contrast to e.g. Claude Desktop App). It would be great if SVG, PNG images and diagrams created with PlantUML/Mermaid or some chart frameworks could be created on demand and rendered in the chat, e.g. for architectural overviews, networks, dependency graphs, etc.
• Images as inputs: It would be helpful if images (or even short videos) could be used as input (similar to Gemini), e.g. with screenshots of apps with unexpected layouts, error messages, any unexpected behavior, or sketches of what to implement.
• Interact with IDEs: I'd like to keep the GH Copilot Desktop App as a stand-alone client, but give its agents the ability to reach into a running IDE (VSCode, IntelliJ, Eclipse) — via MCP servers or IDE APIs — and act the way developers would in the IDE, i.e.:
  • read errors, warnings, issues produced by the IDE (including those from various extensions / plug-ins like SonarQube, Spring plug-ins, etc.),
  • use the IDE's full language support (via LSP?): searching references, call/type hierarchies, performing refactorings, etc.
  • use the IDE's support for build tools and for ecosystem-dependent files like MANIFEST.MF or plugin.xml in Eclipse plug-in development (PDE)
  • trigger IDE actions: for example, debug running applications, set breakpoints, and check field values at runtime
  • "see" the running application's UI (e.g. check layout / rendering so that it can be improved)
  • Letting agents work with the IDE like developers would make the agents more capable, their results more deterministic, less error-prone (e.g. IDE refactorings beat grep-and-replace via CLI), and would let them consume fewer tokens
• UI/UX improvements
  • Session-attached files difficult to access: Opening review panel, pressing "+" and selecting "Files" only shows files in the workspace. You have to press Ctrl + P and scroll down to find session-attached files, i.e. files in your session's folder "files". Such files would be much more helpful if they were easier to access.
  • Buggy Markdown parser / renderer: If fenced code blocks are in a Markdown file, everything after a fenced code block is rendered as if it were part of the code block.
  • Session grouping by tasks/projects: I often work on multiple related git repos at once to complete some task spanning over multiple repos. It would be great to group sessions based on tasks or projects (potentially spanning multiple git repos) rather than on git repos only.
  • Review panel on other screen: The review panel (with the plan.md, diffs, session-attached files, etc.) demands a lot of space on a screen. It would be great if it could be placed in a separate window on another screen.
  • Thinking output collapsed: I'd prefer seeing the thinking output while it is streamed. It might be a good idea to automatically collapse a thinking block as soon as the thinking output streaming completes.
  • File icons: Instead of using different icons for different file extensions, I'd prefer using different icons for different kinds of file access, e.g. read, write, maybe even depending on various tool calls used to access the files.

[voyager163]

I work on multiple azure tenant for different projects. As Github Copilot app is dependent on the az login. It is always lock to one specific az tenant. I have to switch non-stop. It will be good that you can set azure tenant and subscription configuration for each project.

[scottchanman]

I like how the app creates branch names but its not usable for our enterprise. For our large enterprise we have branch naming rules and we are not using worktrees. I tried to name a branch to go along with our rules and its not usable for our rule sets. If we want to be able to work from the app we need to be able to create the branch in this format: users/joesmith/20260729_PE-330 the Jira ticket number is after the date.
Let me know if I'm missing anything or if I'm misinformed.

[Josemarito]

Increible pérdida de tiempo!
Después de varios días tratando de desarrollar un plugin sencillo para wordpress con woocommerce, predesarrollado en chtagpt, con gitHub Copilot mi plugin no ha añadido ninguna funcionalidad. Ni siquiera el plugin se puede instalar en wordpress.
Si esta es la propuesta de la IA con Copilot y GitHub, no pierdan el tiempo y no la utilicen. ¡Es malísima!

[titan-ron]

1. What have you tried doing with the app so far, and why?

Using it as a multi-repo, multi-org command center — several project sessions in parallel (each on its own worktree/branch), reviewing PRs, triaging issues/discussions across repos, and delegating coding tasks to per-session agents. The lightweight chat session for quick cross-repo research and navigation is my most common entry point.

2. What has been most useful? What tasks is it particularly suited for?

The parallel-session model is the standout — kick off work in one repo, hand it to an agent, jump to another session without losing context. It's genuinely different from a single-threaded CLI or IDE chat, and it's especially strong for cross-repo triage and orchestrating several independent changes at once. As I put it in [#2366], the most valuable part of this app isn't the agent itself — it's everything around it: one isolated worktree per session, My Work as a single queue, canvases, diffs, and the PR lifecycle.

3. How does this compare to other tools (Copilot in IDE, Claude Code, Codex)?

Better: a uniform, dedicated window I can put on a second screen instead of switching between VSCode/IntelliJ/Eclipse integrations that each look different; tight GitHub integration; and multi-session orchestration. Worse: it's a separate context from where I run/debug code, so there's round-tripping when testing against live environments — and, critically, it doesn't handle multiple accounts the way the IDEs (built on the CLI) do.

4. What is missing or confusing?

My biggest friction is multi-account / multi-org support, and several things I've filed all stem from it:

• Multiple accounts don't work ([Can not work with multiple accounts #1726]). I can't connect two accounts and pick which Copilot license/limit to use per repo. One account's limit blocks my session; removing it means I can't commit against those repos without workarounds. VSCode/IntelliJ handle this fine via the CLI.

• Ambiguous project names across orgs ([Add configuration to include org/owner name in project's default display name #2513]). Projects show only the repo name (app), so github/app and acme/app look like duplicates. An option to show the full owner/repo would disambiguate the sidebar.

• No control over where PRs/issues open ([Let me choose where clicking a pull request or issue opens: in-app session vs browser #2364]). Clicking a PR always does the same thing — I'd like per-entity-type "open behavior" (in-app session vs browser).

• Session cross-referencing and bulk management ([Make it easy to reference one session from another: copy session reference, @-mention sessions, clickable session chips #2368], [Bulk session management: filter and delete sessions by repo or org, and control whether sessions sync to the cloud #2367]) — @-mentioning sessions and filtering/deleting sessions by repo/org.

5. What do you still go to github.com or other tools for?

Running/debugging code against live services, heavier PR review flows, and anything requiring an account whose license the app can't currently juggle.

6. Magic wand?

First-class multi-account/multi-org support (pick the license per repo, disambiguate same-named projects), a pluggable agent runtime per session via ACP ([#2366]), and per-entity open-behavior config. Multi-account alone would remove most of my daily friction.

[Chriz76]

Have an existing software project on GitHub. wanted to do smaller adjustments mobile with AI support and it is not working like expected.

I use a workflow of ask, plan, agent, iterate.

Ask mode in the app uses only the web indexing and therefore doesn't work on other branches.

Agent mode takes minutes to start the environment and checkout the code. That would be ok if it would keep the environment for the session. But it reinitializes it for every prompt. So it is unusable for my workflow.

Instead I try Codespaces in my mobile browser but the UI is not useable.

Shouldn't be that hard to make this work. Hoping for the next releases. But will try codex on mobile next month.

[karelz]

Copilot app loses unsaved prompt edits when switching sessions

Environment: GitHub Copilot app 1.0.79-9 on Windows

Steps to reproduce:

1. Open a conversation containing a previously submitted prompt.
2. Edit that earlier prompt without submitting the edit.
3. Click away or switch sessions.
4. Return to the original conversation.

Expected: Preserve the edited draft across navigation/session switches, or warn before discarding it.

Actual: Only the original submitted prompt remains. The edited text disappears without warning or recovery, potentially losing substantial user-authored content.

The GitHub Community feedback route is unavailable to my Enterprise Managed User account, so I am reporting this through the official Copilot App feedback thread instead.

[karelz]

Windows taskbar shows a false “1 unread message” badge

Environment: GitHub Copilot app 1.0.79-9 on Microsoft Windows 11 Pro 10.0.26200 (build 26200)

Steps to reproduce:

1. Open the GitHub Copilot app on Windows.
2. Observe the red 1 badge on the Copilot taskbar icon.
3. Check the app for unread messages, pending requests, or sessions requiring attention.

This happened several times. Sometimes it goes away, but came back at least 2-3x so far.
Idea for solution: Have a view for not visible notifications? ... especially if there is plenty projects, etc.

Expected: The taskbar badge appears only when the app has an unread message or pending item, and disappears when nothing needs attention.

Actual: The taskbar icon says there is 1 unread message, but there is nothing unread or pending anywhere in the app.

Impact: The persistent false notification is distracting and makes the taskbar status unreliable.

Screenshot:

[daweins]

Suggestion: detect and recommend Windows Dev Drive

On Windows, Copilot App should check whether both the source repository and the configured Copilot storage/worktree location are on a Windows Dev Drive. If not, show a dismissible nudge explaining the likely benefit and linking to setup/migration guidance.

In a controlled A/B test on the same machine, using matched full clones at the same commit and an identical eight-worktree creation workload, Dev Drive produced:

• 21% faster total batch completion
• 44% faster active Git checkout
• 39% lower Git CPU time
• 47% higher write throughput

This is especially relevant to Copilot App because its workflow actively encourages frequent parallel work across isolated sessions, with new worktrees created as a normal part of starting that work. This is not an occasional manual Git operation: the cost repeats and compounds as users open more concurrent sessions. Even when worktree creation is internally serialized, faster storage directly reduces the accumulated startup delay before the parallel work can become productive.

The focused Defender measurements were roughly equivalent, so the improvement appeared to come primarily from filesystem/Git efficiency. The app serialized the eight requested worktree creations, which made per-checkout storage latency compound across the batch.

Suggested UX:

• Perform the check locally; do not upload repository paths.
• Check during onboarding and when the storage location changes.
• Check both the repository/object-store location and Copilot's worktree root.
• If applicable, also indicate whether Defender performance mode is enabled for the Dev Drive.
• Explain the expected benefit, link to Microsoft Dev Drive guidance, and let the user dismiss the recommendation.
• Do not move repositories automatically.

This seems like a relatively low-cost check that could materially improve startup and multi-session performance for Windows users working in large repositories.

[daweins]

Sleeping sessions should support transcript-only viewing

When I open a sleeping session, the app appears to pay the full wake-up cost before letting me review its transcript. That makes historical review and session triage unnecessarily slow.

Please decouple viewing durable session history from activating the agent runtime:

• Render the locally cached transcript immediately in read-only mode.
• Keep the session asleep while I scroll, search, or inspect prior work.
• Wake it only when I submit a new turn or explicitly select Wake session.
• Show a clear status such as “Sleeping — sending a message will wake this session.”
• Allow transcript search and metadata-based triage across sleeping sessions without activation.

Conceptually, the transcript/event log and session metadata are durable state, while the CLI/agent process, MCP servers, workspace checks, and any cloud environment are live runtime state. Restoring that runtime may legitimately be expensive, but merely reading the persisted conversation should not require it.

This would materially improve workflows where users frequently revisit old sessions to understand decisions, compare approaches, or decide which sessions should be resumed, archived, or left alone.

Update: measured local-session switch latency

I measured several cold switches after disabling an optional integration that made the delay significantly worse. Even without that integration, four recent session resumes took 4.49s, 5.29s, 5.63s, and 6.68s from runtime-resume start; including frontend/preflight work, perceived latency was roughly 5–7.5 seconds.

The persisted transcript was not the bottleneck: disk-history parsing completed in only 27–183ms. The remaining time was spent eagerly starting the Copilot CLI (1.7–2.5s) and reconnecting/restoring the live SDK session, permissions, extensions/MCP state, and workspace context.

This makes the opportunity concrete: the transcript is available locally in well under 200ms, but review is coupled to several seconds of runtime activation. Showing disk-backed history immediately and deferring runtime resume until the next submitted turn would make session review and triage feel effectively instant.

[JakubAnderwald]

I'm trying to use it as a daily workhorse for me in the company instead of Copilot CLI. I love the frequent updates with new features and problem solutions. I still find it's less reliable than CLI (sessions hung, don't start, cannot create a worktree etc.) but it's getting better every week.

What I especially love about the app is that it has a user-friendly UI. There's a lot of people in our company who need the GH copilot power at their fingertips, but are alergic to terminal. Github Copilot app seems to be the solution for especially those non-developers that are suddenly becoming empowered.

We observed one issue that's stopping us from sharing the app very broadly. Hope you can try and solve it for us. It's the security of PAT for MCP servers that don't use OAuth. The situation is:

• VSCode has a built-in mechanism to store those tokens securely
• For Copilot CLI we can use keychains in Windows/macOS and load the tokens into shell with a shell startup-script and that way CLI has access to them as a system variable
• Github Copilot can use the same mechanism only on macOS (through zshrc file that gets called when a Copilot CLI is launched underneath Github Copilot), but that's only macOS
• We DID NOT find a way for Github Copilot to securely store PATs. We need to keep them in plain text in the mcp.json config file. That's something we don't want to do.

[antonioatkinson]

Plugin update fails on private marketplace authentication, then on a live directory lock

Environment: GitHub Copilot app/CLI 1.0.80 on Windows.

Updating a plugin from a private GitHub marketplace failed in two stages:

1. Marketplace cloning failed with fatal: unable to get password from user, despite valid credentials for two stored GitHub profiles. An authenticated non-interactive clone into the expected marketplace cache succeeded, allowing the update to advance.
2. Installation then failed with Failed to install plugin: Access is denied. (os error 5). The plugin directory ACL granted the current user full control, no files were read-only, and every file could be opened exclusively. However, renaming the plugin directory failed while the Copilot app was running. Copying the new files in place succeeded, indicating that a Copilot plugin host held a directory handle that blocked the updater's replacement strategy.

The workaround also exposed split state: after the plugin manifest and files were updated, copilot plugin list continued reporting the old version from ~/.copilot/config.json until its installation record was synchronized.

Suggested improvements:

• Support explicit GitHub-profile selection for private marketplaces and avoid credential flows that require an interactive prompt.
• Distinguish fetch, staging, replacement, and registry-update failures in the error message.
• Detect a directory lock and identify whether a Copilot-owned process holds it.
• Offer a restart-and-finish-update workflow when the running app prevents replacement.
• Make installation transactional so plugin files and the installed-version registry cannot diverge.
• Include the affected path and diagnostic log location in the error details.

Expected behavior: The app should fetch with an available authenticated profile, stage the update, safely release/restart the plugin host when needed, atomically replace the plugin, and update its registry record.