Taking Google Tasks out of the browser: notifications without the browser open

Searching for a Google Tasks desktop app usually starts with a specific annoyance. A task had a date and a time on it, the reminder was supposed to appear, and it did not, because the browser had been closed hours earlier. The list itself is not the problem. The problem is that the list lives inside a tab, and a tab only exists while something is holding it open. That is a solvable problem on a Mac, but not by downloading anything from Google.

What Google actually ships for Tasks

Google's own support page for getting started with Tasks names the places the product is available, and a desktop application is not among them. It points to the Play Store for Android devices and the App Store for iOS devices for the mobile apps. For a computer, it says that "From your computer, you can access Tasks in Calendar in your browser." Everything else on that list is a side panel inside another Google product: Gmail, Calendar, Chat, Drive, Docs, Sheets, and Slides.

That is the full official surface. Two mobile apps, and a panel that appears inside other web products.

The address bar answer

The obvious thing to try is tasks.google.com, on the assumption that it works like mail.google.com or calendar.google.com. It does not. Opening tasks.google.com without a signed in session returns a redirect to Google's Workspace product page for Tasks, which is a marketing page describing the features. There is no equivalent of a full window Tasks application at its own address, which is why so many of the results for this search are third party products rather than a download link from Google.

What the third party results are offering

The pages that rank for this query fall into three groups, and the distinction matters before spending money. Some are separate applications that connect to a Google account through the Tasks API and store the data on Google's side. Some are Chrome extensions that open the same web interface in a smaller window. Some are full screen web services that give Tasks a board layout and charge a subscription for sharing and themes. All three are somebody else's product holding an account token. That is a reasonable trade for the right feature set, and it is a large trade to make if the only thing wanted was a window that stays open.

Why the reminder question has a precise answer

The reason a task reminder goes missing is documented by Google, and it is worth reading closely because it explains what a Dock icon actually fixes.

Tasks with a date and a time do reach the calendar. Google's product page states that adding a date and time to a task means "it automatically appears in your Google Calendar", and that a date or time on a task is what produces a reminder at all. So the reminder exists. The question is what surface delivers it.

Google Calendar's notification settings page lists three delivery methods. By email, where the update lands in a mailbox. As alerts, which show up inside the Google Calendar window. And as desktop notifications, described in Google's own words this way: "When your calendar is open, these pop up outside your web browser."

That sentence is the entire issue. Desktop notifications from Calendar escape the browser chrome and appear as system notifications, but only while the calendar is loaded somewhere. Close the last window, or quit the browser at the end of a session, and the thing that was going to fire the notification is no longer running. Nothing is broken. The delivery mechanism simply requires a page that is still there.

A separate application in the Dock is a page that is still there. It survives quitting Safari or Chrome, it can be set to open at login, and it does not get closed by accident during a tab cleanup.

What a standalone window changes, and what it does not

macOS has shipped a first party way to do this since Sonoma. Apple's support note on Safari web apps explains that from macOS Sonoma 14 onward, a webpage can be saved through File then Add to Dock, and that the result "functions independently of Safari", sharing no browsing history, cookies, website data, or settings with it. The app is saved to the Applications folder of the home folder, which is a per user location, so no administrator password is involved on a managed machine.

Three things follow immediately. The window has a Dock icon and an entry in the application switcher. It can be quit on its own without touching the browser. And it holds a session that is separate from the browser session, which is what makes a second Google account possible without signing anything out.

The notification detail that trips people up

Apple's documentation is specific about one step that is easy to get wrong. A web app's Dock icon can show the number of unread notifications as a red badge, but "to use this feature, respond to the website's notifications request in the web app, not in Safari." A permission already granted to the site inside Safari does not carry across, because the web app keeps its own website data. The web app then appears by name in System Settings under Notifications, listed as the name of the web app rather than the URL.

So the sequence matters. Build the window, open Calendar's notification settings inside that window, choose desktop notifications there, and accept the system prompt in that window. Doing all of it in the browser first and then building the window produces a window with no permission.

What it does not change

A standalone window does not create an offline task list. The interface is still the web interface, and it needs a connection to load and to sync. It does not add features Google has not built, so a board view or shared lists across a team remain outside its scope. And it does not change where a link opens: a calendar URL clicked in a chat message still goes to the default browser, because that routing is a system setting rather than a property of the window.

The routes compared

Route	Requires	Session	Notification permission
Safari, Add to Dock	macOS Sonoma 14 or later	Separate from Safari	Granted inside the web app
Chrome, Install page as app	Chrome installed	Shared with the Chrome profile	Follows the Chrome profile
A site to app tool	The tool installed	Separate per app	Granted inside the app
Third party Tasks client	An account connection	Its own login	Handled by that product

Chrome's route is documented in its help pages under Use web apps. The path is More, then Cast, save, and share, then Install page as app, and on some sites an install icon appears at the right of the address bar instead. The important property is the one that does not show up in the menu: an installed Chrome web app belongs to the profile that created it. The Google session in that profile carries straight in, which removes a sign in step and also removes the isolation a second account needs. Chrome also notifies about changes to an installed app's name or icon and offers to update, ignore, or uninstall, which is worth knowing before wondering why a dialog appeared.

Keeping the window alive, and keeping two of them apart

A window that has to be opened by hand every morning solves nothing, because the morning is exactly when the first reminder is due. Apple's note on web apps mentions the fix in passing: a web app can be added as a login item so that it opens automatically at login. Setting that once turns the arrangement from a habit into a default, and it is the difference between a reminder system and a reminder system that works on the days nobody remembers to open anything.

Quitting behaviour is worth deciding on at the same time. A window that gets quit with Command Q at the end of every task is back to the original problem. The practical pattern is to treat the window like a background utility rather than a document: opened at login, hidden rather than closed, and quit only when something is actually wrong with it. On a Mac that means it lives in the Dock and the switcher without occupying a space in the browser's tab bar, which is usually what people wanted when they went looking for an application.

Two accounts, two windows

The account problem is the other half of why a single browser tab stops being enough. A personal task list and a work task list under two different Google accounts cannot both be the active account in one browser profile. Google's account switcher makes them reachable, not simultaneous, and a reminder only fires for the session that is loaded.

Two separate windows remove the switching entirely, because each one carries its own cookies and its own storage. The practical requirement is that they are distinguishable at a glance. Two identical calendar icons in the Dock are worse than one, since every click becomes a guess. Setting a different icon and a different name for each is a one time step in the settings panel, and it is the step that turns two windows into two places rather than two copies of the same thing.

Choosing what the window opens on

This is where the effort pays off, and it is the step most people skip. Since Tasks has no address of its own, the window has to be built from the surface that actually holds the list. Google Calendar in a browser shows Tasks alongside events and is where dated tasks land, so a Calendar window covers both the reminder and the list in one place. A Gmail window with the Tasks panel open covers a different habit, the one where tasks get created out of mail all day.

Naming the window after the job rather than after the product is the other half. A switcher entry reading Calendar, or better, reading the name of the work that calendar is for, is more useful than one reading Google. With two accounts, two windows with two names and two icons remove the step of checking which account is loaded before reading anything. Supported services lists the sites that most often end up handled this way, and the Guide covers how the window rules and icons get set.

Extensions and passwords, on the first day

One surprise is reliable enough to plan for. A Safari web app does not inherit Safari extensions by default. They are enabled per web app from the Extensions tab in its settings panel, which means the first sign in happens in a window that has never seen the password manager. Doing that first sign in before building a workflow around the window avoids a confusing minute later. The same settings panel is where the Application URL can be retyped or set to the current page, so a window built on the wrong screen is a two second fix rather than a rebuild.

What to change first

Build one window from Google Calendar, sign in there, and turn on desktop notifications inside that window rather than in the browser. Then leave it running for a week and watch whether the missed reminders stop. If the answer is yes and the next thing wanted is a second account or a window per project, Kagemusha is built for that shape of work.