Desktop app

The taiku desktop app is a native application built with Tauri, a Rust-based framework that wraps web content in a lightweight native window. Unlike Electron-based apps, Tauri does not bundle a full Chromium installation. Instead, it uses the operating system's native webview (WebKit on macOS, WebView2 on Windows), resulting in a smaller binary, lower memory usage, and tighter integration with the host OS.

The desktop app provides everything the browser experience does, plus a set of capabilities that only a persistent native process can offer: background device presence, remote session launching, native recording, and app-level window management.

Installation

Download the desktop app from the downloads page. On macOS, mount the .dmg and drag taiku to your Applications folder. On Windows, run the installer. On Linux, use the provided .AppImage or .deb package.

The desktop app shares credentials with the CLI. If you have already run taiku login, the desktop app picks up your credentials automatically from ~/.config/taiku/credentials. There is no separate sign-in flow.

First launch

When you open the desktop app for the first time, it loads the taiku dashboard. From here you can see your active sessions, your registered devices, and start new sessions directly.

The window uses a custom titlebar that blends with the taiku interface. On macOS, the traffic light buttons (close, minimize, zoom) are integrated into the titlebar area. Standard keyboard shortcuts work as expected: Cmd+T for new tab, Cmd+W for close tab, Cmd+R for reload, and Cmd+Ctrl+F for fullscreen.

The app also provides native menu bar integration with Edit (undo, redo, cut, copy, paste, select all) and View (reload, fullscreen, zoom) menus, so clipboard and navigation operations feel native rather than web-mediated.

How it differs from browser-only usage

In a browser, taiku is a tab. When you close that tab, you disconnect from the session. There is no background presence, no way for other devices to reach your machine, and no persistent identity beyond your login session.

The desktop app changes this in three important ways.

It stays running in the background. Even when you close the session window or navigate to the dashboard, the app process remains alive. This persistent process is what enables device registration and remote access.

It registers your machine as a device. On launch, the app reads your CLI credentials and registers the machine with the taiku server, reporting the device name, hostname, and operating system. This registration appears on the dashboard and on other devices that share the same account.

It enables remote session launching. Because the device is registered and the app is running, you can start a new session on that machine from the dashboard on any other device. The command travels from the dashboard through the server to the desktop app, which spawns the taiku CLI locally.

Persistent presence and heartbeats

The desktop app maintains its "Online" status by sending heartbeats to the server every 30 seconds. Each heartbeat includes the device ID, device name, hostname, OS, and optionally the URL of an active session. This is how the dashboard knows which of your devices are available for remote session launching.

The heartbeat mechanism uses two parallel systems:

File watcher (fast path): The CLI writes its session URL to ~/.taiku-desktop-url immediately on startup. The desktop app polls this file every 500 milliseconds. When it detects a new URL, it navigates the window to the session and sends a heartbeat with the session URL. This gives near-instant local session detection.

Server poller (remote path): The app long-polls the server's command queue endpoint. Each request blocks for up to 30 seconds, waiting for commands. When you click "Start session" on the dashboard for a remote device, the command is queued server-side and delivered to the desktop app on the next poll. The app then spawns the CLI, which writes the session URL, and the file watcher picks it up from there.

This dual approach means local session starts are nearly instantaneous (under a second), while remote session starts take a few seconds for the command to propagate.

Remote session launch

From the dashboard on any device, you can select one of your registered machines and start a session on it. The flow works like this:

1. You click "Start session" on the dashboard, optionally configuring a working directory, sandbox path, or viewer auth settings.
2. The dashboard sends a command to the server, which queues it for the target device.
3. The desktop app on the target machine receives the command via long-polling.
4. The app spawns taiku --no-app --no-browser with the requested configuration, running in the specified working directory.
5. The CLI starts the session, writes the URL to the signal file, and the desktop app navigates to it.

This means you can start a terminal session on your office machine from your laptop at home, or on a cloud workstation from your phone. The session runs with the same permissions, filesystem access, and shell environment as if you had typed taiku in a terminal on that machine.

Recording

The desktop app includes native recording support. You can record the entire application window or a specific tile region.

On macOS, recording uses the native screen capture APIs. This avoids the browser screen-share permission prompt that you would encounter in a regular browser tab. You select what to record, and the app captures it directly. The recording controls are accessible through the app's Tauri commands (start_recording_window, start_recording_region, stop_recording).

In a browser, screen recording requires the WebRTC screen capture flow: the browser presents a system picker asking which window or screen to share, and you must select the correct tab or window. The desktop app eliminates this friction because it already has access to its own window content.

Browser tiles

The desktop app includes a built-in browser that can be tiled alongside terminals in your workspace. Unlike iframes in a web browser (which are subject to cross-origin restrictions and sandboxing), the desktop app creates native child webviews that load arbitrary URLs with back/forward navigation, find-in-page, and independent data clearing.

You can open any link from a terminal directly into a browser tile. Clicking a URL in terminal output opens it as a tiled pane rather than switching to an external browser. This keeps documentation, dashboards, and web tools inside your workspace. Tunnel previews also render in these native webviews, which means fewer cross-origin issues than iframe-based approaches in the browser.

Native notifications

The desktop app delivers notifications through the OS notification system. On macOS, it uses osascript to display banner notifications, bypassing the permission quirks that can cause Tauri's notification plugin to silently succeed without showing anything. On other platforms, it uses the Tauri notification plugin with standard permission prompting.

This means chat messages, session events, and other notifications appear as native system notifications rather than in-browser toasts.

When to use desktop vs. CLI vs. browser

Use the desktop app when you want your machine to stay reachable from the dashboard, when you want native recording, or when you prefer an app-like window over a browser tab. The desktop app is the best default for development machines that you use regularly and want to access remotely.

Use the CLI directly for server workflows, automation, CI environments, or any context where a GUI is unnecessary. The CLI is a single binary with no dependencies and no window. It is the right choice for headless machines, Docker containers, and scripted session creation.

Use the browser when you are joining someone else's session, when you are on a machine where you cannot install software, or when you want the simplest possible entry point. The browser experience requires no installation at all.

All three share the same underlying protocol and encryption. The difference is in how the session is launched and what peripheral features (recording, device presence, remote launch) are available.