[FEATURE] Claude Desktop: make quitting discoverable instead of burying it in the hamburger menu

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Scope note: this is about the Claude Desktop app's chat-side UI, not the Claude Code CLI. I'm filing here because the desktop app ships Claude Code and this is the closest public tracker I could find. If this isn't the right venue, I'd appreciate a pointer — as far as I can tell there is no publicly documented channel for Claude Desktop UX feedback, which is part of the problem below.

My workflow: I keep Claude Desktop resident in the system tray and use it throughout the day, but I also fully quit it regularly — before shutting down, when freeing up memory, or when troubleshooting. So "quit completely" is a routine operation for me, not a rare one.

The problem: I can't find that action when I need it. It sits several levels deep inside the hamburger menu, so every time I want it I end up hunting through submenus. What I actually do now is kill the app from Task Manager. That isn't a preference — as far as I can tell it's the only reliable way to fully quit. The keyboard shortcut behaves like an ordinary window close, leaving the app resident, so there is no quick path to a real quit at all. Ending up at an OS-level process kill means the in-app path isn't functioning as a path.

Closing the window with X compounds this: the app keeps running with no indication either way, so I'm left unsure whether it actually quit, which sends me back to Task Manager to check.

This isn't a new-user problem. I use this app daily and I still have to look for it. When a primary, frequently-used action can only be reached by searching, the interface isn't doing its job — and "you learn where it is eventually" isn't a strong answer for an action this common.

Why tray residency isn't a sufficient justification here

Staying resident makes sense when something is actually running in the background — an active Cowork session, a long-running Code task, a pending Dispatch request. Quitting abruptly in those cases would discard real work, so a resident default is the right call there.

But that reasoning doesn't extend to chat-only use. If I've only been having a conversation, nothing is running, nothing is at risk, and there is no reason for the app to outlive the window I just closed — yet quitting is harder than in an application that has no background work at all.

The cost of the resident-by-default design is being paid by users who never touch the features that justify it. And those are disproportionately the users least equipped to understand why the app behaves this way, since they never see Cowork or Code at all. At minimum, the choice should be surfaced rather than assumed.

Proposed Solution

Make quitting a first-class, one-click action, with a clear choice at the moment the user closes the window.

1. A persistent quit control at the top level.

A power icon in a fixed position — top-left or bottom-left of the window chrome, near the account area — so quitting is one click from anywhere in the app, with no menu traversal. Position matters less than persistence: it should always be in the same visible place.

2. A choice when the window is closed.

Clicking X currently hides the app silently. Instead, present the two outcomes explicitly, and let the user make it permanent:

• Buttons: "Quit" / "Keep running in the background"
• A "Don't ask again" checkbox that remembers whichever option was chosen, so the dialog appears once and never again
• Default focus on "Keep running in the background", so accidental Enter presses don't kill a resident app

Rough shape:

if (!settings.dontAskOnClose) {
  const choice = await dialog.showMessageBox({
    type: "question",
    message: "Quit Claude completely?",
    buttons: ["Quit", "Keep running in background"],
    defaultId: 1,
    cancelId: 1,
    checkboxLabel: "Don't ask again"
  });

  if (choice.checkboxChecked) {
    settings.dontAskOnClose = true;
    settings.dontAskOnCloseAction = choice.response === 0 ? "quit" : "hide";
  }

  choice.response === 0 ? app.quit() : win.hide();
}

The two pieces are the same flow: one gives you the action on demand, the other tells you what just happened when you close the window. Together they mean a user never has to guess whether the app is still running, and never has to reach for Task Manager.

This costs nothing for users who keep the app resident — they simply never click the icon and dismiss the dialog once. It removes a recurring annoyance for everyone else.

Alternative Solutions

Workarounds I currently use:

• Task Manager (Windows) — this is what I actually do, and as far as I can tell it's the only way to reliably quit the app completely. It works, but it's an OS-level kill rather than a graceful quit, and it means leaving the app entirely to perform one of the app's own basic operations.
• Hunting through the hamburger menu — the intended path. It works once found, but I have to re-find it each time, so in practice I stop using it.

I want to note what isn't on this list: there is no keyboard path. The shortcut closes the window the same way X does and leaves the app resident, so it isn't a workaround for quitting — it's another way to end up unsure whether the app is still running.

Alternatives considered for the feature itself:

• Just documenting where the menu item is. Doesn't help — the problem is discoverability at the moment of need, not knowledge. Documentation can't be consulted in the half-second where I'd otherwise just click something.
• Making the existing shortcut actually quit. This would be an improvement, but a shortcut isn't discoverable on its own, and on its own it wouldn't resolve the "did it actually quit?" ambiguity after closing the window.
• Making X always quit. Rejected — that breaks the tray-resident workflow for users who rely on it. That's exactly why the dialog with a remembered choice is the better shape: it serves both behaviours instead of picking a winner.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

A typical day:

1. Morning — I launch Claude Desktop and leave it resident in the system tray. I use it on and off for several hours.
2. Afternoon — I'm about to run something memory-heavy, so I want Claude fully closed, not just hidden. I click the X. Nothing visible happens; the app is still resident, but I can't tell that from the UI.
3. I open the hamburger menu and start looking for a quit option. I don't remember where it is, so I open a couple of submenus before finding it — or give up.
4. I open Task Manager, find the Claude processes, and end them. Roughly 20–30 seconds for an action that should be one click.
5. Evening — same thing before shutting down the machine.

With the proposed change, step 2 becomes the whole interaction: I click X, a dialog asks whether to quit or keep running, I pick "Quit", and optionally check "Don't ask again" so it never asks me twice. Steps 3 and 4 disappear entirely.

The frequency is what makes this worth fixing — it's not a once-a-month papercut, it's several times a day, and the current answer is "leave the app and use the OS".

Additional Context

On where this feedback belongs

I want to flag something adjacent, because it's part of why this is being filed here.

Before opening this issue I tried the documented support paths. The in-app support messenger routed me to an AI agent, which acknowledged the feedback and then told me to submit it via "the support center" — while I was already in the support center. It also stated plainly that there is no way to track whether a request like this gets acted on. The official support documentation describes support entirely in terms of resolving account and technical problems; there is no defined channel for product feature requests at all.

So the practical situation is that this GitHub repository is the only feedback route for Claude Desktop that is public, trackable, and read by engineers — and it requires a GitHub account and familiarity with issue conventions to use.

That has a selection effect worth naming: the users least likely to clear that bar are exactly the ones most affected by chat-side UI friction. Desktop UX complaints are structurally filtered out before they reach anyone. I suspect that's part of why an issue like the one above persists — not because nobody minds, but because the people who mind have nowhere to say so.

If Claude Desktop UI requests aren't in scope for this repository, I'd genuinely like to know where they should go. If the answer is that no such place exists, that seems worth fixing on its own.