[Feature]: Add a system tray or menu-bar icon for background status and controls

[ElliotDrel]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/desktop, desktop lifecycle, and T3 Connect

Problem or use case

When T3 Code is running, there is no persistent system-level indicator comparable to the tray icons or menu-bar icons used by other background applications.

That makes it difficult to tell whether T3 Code, its backend, and the local T3 Connect environment are still running after the main window is closed or hidden. It also makes background startup less understandable because the user has no obvious place to confirm status or reopen the app.

Proposed solution

Add a persistent T3 Code icon in the Windows system tray, macOS menu bar/status area, and the appropriate Linux notification area where supported.

The icon should make it obvious that T3 Code is running and provide quick access to basic status and lifecycle controls.

Expected behavior

• Show a tray/menu-bar icon while T3 Code is running in the background.
• Clearly indicate whether the local T3 backend or T3 Connect environment is online, starting, disconnected, or experiencing an error.
• Provide a menu with at least:
  • Open T3 Code
  • Show/Hide window
  • current environment or connection status
  • Quit T3 Code completely
• Optionally show useful lightweight information such as active/running session count.
• Make the distinction between closing the window and quitting the application clear.
• Offer a setting for whether closing the main window keeps T3 Code running in the tray or exits completely.
• Preserve active sessions and remote availability when the window is hidden but the application remains running.

Why this matters

T3 Code can act as a persistent remote environment through T3 Connect, so users need a dependable way to know whether it is still available. A tray/menu-bar presence makes its background behavior visible and reduces accidental shutdowns.

It also pairs naturally with a Launch at login option: T3 Code could start quietly in the background while still giving the user an obvious status indicator and a way to open or quit it.

Smallest useful scope

A first version could include:

• a persistent tray/menu-bar icon;
• Open/Show and Quit actions;
• a simple online/running status;
• a setting to keep running when the main window closes.

More detailed session status, notifications, and per-environment controls could be added later.

Related request

See #5510 for launching T3 Code automatically at system login.

[DAGGE3R]

Hope this gets noticed .

[cestercian]

I can take this on. I’ve built a similar macOS menu-bar usage popup in Bridge and would like to contribute one to T3 Code. I can share screenshots of the Bridge implementation.

Proposed initial scope:

• Menu-bar icon with Open T3 and Quit controls.
• Compact Claude/Codex quota cards showing five-hour and weekly limits, reset countdowns, and refresh status.
• Reuse T3’s existing usage services and credentials.
• Keep quota refresh available when the main window is closed.

I’ve reviewed the tray foundation in #10163 and would use it as a reference.

@juliusmarminge would you approve this direction and scope?
I’d start with the macOS menu-bar icon and Open/Quit controls, then add the usage popup using T3’s existing quota services.

[luigisoares]

Hi! I'd like to gently add my support for this one, especially the close-to-tray behavior on Windows.

Right now, closing the window on Windows quits the whole app along with any running agents (the main process calls app.quit on window-all-closed outside macOS, also reported in #10161). Being able to close the window and have T3 Code keep working quietly in the tray would make a real difference for long-running sessions.

If it fits your plans, something along these lines would be lovely:

• The X button sends the window to the system tray instead of quitting; agents keep running.
• A tray / menu-bar icon with Open T3 Code and Quit, which would benefit macOS users as well.
• Quitting stays deliberate (tray → Quit, or hold-Ctrl+Q), maybe with a setting for those who prefer the current behavior.

I know a few community PRs explored this (#7493, #10163) and are waiting on a decision about direction, so I just wanted to share that it would mean a lot to those of us on Windows. Totally understand if it's not a priority right now. I'd be glad to help test on Windows anytime.

Thanks for all the work on T3 Code. This is one of the small things that would make it feel like home.

---

_{✍️ Written by Claude (Opus 5.5) on behalf of @luigisoares, who brought the idea and reviewed it.}

[Paranjayy]

Windows close behavior: request for direction and scope

Following Maria's feedback on #19176, I am bringing the Windows proposal here alongside the existing request and Windows feedback. I submitted that PR before obtaining direction approval. That was premature; I will wait for explicit agreement on direction and scope before requesting reconsideration.

The problem I want to solve is losing running work when I close the Windows desktop window. I want to start an agent task, close the window, and return later to the same running host. Today, closing the last window also quits that host, interrupts local work, and disconnects clients using it remotely. #10161 describes the Ctrl+W path; #10697 describes the title-bar X path. Minimizing is a workaround, but it does not protect either close action.

This matters for T3 as both an agent interface and a host: removing its window from the desktop can also remove the environment another device is using. It is useful even without launch-at-login, usage widgets, or a broader tray dashboard.

What the earlier attempts establish

There is useful history here, but it does not amount to approval:

• In #10697, Julius recognized the Windows gap and left the enhancement unaccepted pending a choice between close-to-tray and confirmation while a turn is running. The existing Quit-shortcut confirmation does not cover the title-bar X.
• #8423 was closed in favor of the narrower feat(desktop): keep Windows host in system tray #7493, with counts and preferences treated as separate additions. #7493 was later closed for missing interaction evidence, including continued remote availability, reopening, and explicit Quit.
• #10163 and my feat(desktop): keep Windows tasks running after window close #19176 lacked the required direction approval. Repeated implementation attempts do not resolve that product decision.

Proposed first scope

My preference is Windows close-to-tray, because it supports intentionally leaving work running as well as accidental closure. An opt-in version would be a reasonable starting point if changing the default is undesirable; it would need a discoverable setting and would still require product approval.

A first version could be limited to:

• A Windows tray with Open T3 Code and Quit T3 Code.
• While keep-running behavior is enabled, closing the last window keeps the existing host and work alive. Tray Open and an ordinary launch from Start or a shortcut return to that same host.
• Explicit Quit and updater shutdown stop the host through the existing shutdown path. A backend restart must not reopen a deliberately closed window, and activation during Quit must not recreate it.
• If tray setup fails, retain exit-on-close behavior so the app is not left inaccessible.

No launch-at-login, running-agent counters, usage panels, Windows service, or macOS/Linux tray changes in that first scope. No promise of surviving explicit Quit, crashes, logout, or shutdown.

Keeping the host alive also keeps its processes and any configured network access alive. That needs to be clear to users and is a reason to decide the default deliberately. The documented background service covers Linux/macOS, not Windows; a separately hosted server is another approach, but does not change the installed Windows desktop's close behavior.

Decision and verification

Would you approve that Windows-only direction and scope, and should it be opt-in or the default? If confirmation only while work is running is preferred, I would follow that direction instead of adding both behaviors.

The existing branch is exploratory evidence, not a reason to accept the proposal. Before reconsideration, verification should include a packaged Windows recording of close, continued agent/terminal work and remote availability, reopen, and explicit Quit, plus startup, tray-failure, backend-restart, and updater checks. Current evidence does not establish all of those paths; packaged follow-up validation and agent continuity remain incomplete.

Prepared with GPT-6.1-sol through the Codex harness in T3 Code.

[opsaaaaa]

#19472 was closed for size, and I'm not going to pursue a PR further. I wrote it to fix #10697 for myself, so here is what it does in case any of it is useful.

What it does

On Windows and Linux, closing the window or quitting asks for confirmation, but only while a thread on this computer is running or waiting on background work (subagents, monitors, background commands). That covers the X button, Ctrl+W, compositor close (Super+Q, Alt+F4), File → Quit, and Ctrl/Cmd+Q after the hold. When nothing is running, the window closes instantly, as it does today. It uses the existing in-app confirm dialog (the terminal-close one), and Cancel leaves the app and the threads running.

How

• The renderer works out how many threads are busy from the thread snapshots it already has, and sends the main process the count whenever it changes. Closing while idle therefore never waits on IPC.
• The main process blocks the window close and app before-quit events while that count is above zero. It asks the renderer to show the dialog and finishes the close only if the user confirms.
• Closing the window and the quit that follows share one confirmation, so the user is asked only once.

Why it's shaped this way

• Only threads in environments this app owns count (the local backend, plus WSL). Remote, SSH and relay threads keep running after the app quits, so asking about them would be a false alarm.
• Every close and quit path goes through the same check. As Julius noted in [Feature]: Prompt for confirmation before closing window when agent tasks are running #10697, quit shouldn't behave differently depending on where it was triggered.
• It never blocks a close it can't confirm. If the renderer reloads, crashes or can't show the dialog, the close goes ahead. Quits from a signal, a relaunch or the updater are never blocked.

The code and recordings are in #19472 if you want them for reference.

Good luck with the fix, and thanks for T3 Code.

[Tariq-Sekhri]

I'd like this. I get that not everyone wants it, so it could be a toggle, off by default.

[MorielLabs]

+1 from a Windows user (T3 0.1.6 desktop).

I leave agents running for a long time on my laptop. Clicking the X closes the whole app and stops every running agent. Ctrl+Q has the hold guard, but the X button doesn't.

What I'd like, as a setting that is off by default:

• Keep running when I close the window. The X hides T3 to the tray. Quit from the tray icon or Ctrl+Q still fully exits.
• Start with Windows ([Feature]: Launch T3 Code automatically at system login #6888), so T3 is up and ready after a reboot.

Together these would let T3 work like a background app on Windows, the way it already does on macOS.

[ovws]

Adding my support for Windows close-to-tray behavior. I would like to close the T3 Code window while the app and active agent tasks continue running in the background, then reopen the window from the system tray. A tray menu with Open and an explicit Quit action would make the behavior clear. A setting to choose between close-to-tray and exit would also be helpful. Thank you!