Ta Desktop

Ta's desktop application: one window displaying the Web client bundled with ta serve. The shell does only what a browser window cannot; everything else is in the Web client.

Electron main process
 ├─ Single instance, menu, external links and permission guards, tray, task completion notifications
 ├─ If ta serve in serve.json is still responding → use it (e.g., started in terminal)
 ├─ Otherwise start the built-in ta serve in Node mode (ELECTRON_RUN_AS_NODE): on macOS use the app's Helper (not in dock), on other platforms use the app itself
 └─ Check every 5 seconds; 3 consecutive timeouts or process exit triggers a restart
              ↓
ta serve (listens only on 127.0.0.1, port and token persist across restarts)

• ta serve started by the app exits when the app quits; if tasks are running, it prompts first. ta serve started in the terminal is unaffected.
• When opened from Finder or Dock, PATH is short, so the app takes the login shell's PATH and passes it to ta serve so the agent can find commands like git and node.
• When closing the window, macOS and Windows continue running in the background (use Dock or tray to bring back), Linux exits (many desktop environments don't show a tray).
• The browser of the workbench shows sites in a <webview> (src/embedded-browser.ts; the preload tells the web client it can): sites that refuse frames open, signing in works and stays in a partition of its own (persist:ta-browser), apart from the web client. Only the page of ta serve may add one, with Node, preload and other webviews off; its pages go only to http(s), get no permission but full screen and writing the clipboard, and introduce themselves as Chrome. A popup with window features (a sign-in that needs window.opener) opens as a window in the same partition, a new tab in the same view, mail in the mail app. The context menu (links, images, editing, back and forward, Inspect) and the shortcuts Cmd/Ctrl+R, F5, Cmd+[ / ], Alt+← / →, F12 act on the page, not on Ta.
• The agent works that page with the DevTools protocol through the preload's debugWebview (EmbeddedBrowser.debug): only from the main frame of the page of ta serve, only to a webview of that page, only the domains that act on the page itself (Accessibility, CSS, DOM, DOMSnapshot, Emulation, Input, Log, Overlay, Page, Runtime), never Network, Storage, Target, Browser, nor the commands that read files, download or navigate around the guard; focus is emulated once the debugger attaches, and a command takes at most 30 s. While the agent works, and 10 s after, the window and the page are not throttled in the background, where every wait would otherwise take a second or more.
• Importing sign-ins (src/browser-import.ts, macOS and Windows): the profiles with cookies of Chrome, Edge, Brave, Arc, Vivaldi and Chromium come from their Local State (the page gets names and ids, never paths); once the user picks one, the app asks in a native dialog, which a page cannot draw. Only then is the key read: on macOS security reads the "… Safe Storage" item of the Keychain, and the system asks once more whether Ta may; on Windows PowerShell's DPAPI unwraps the key of Local State. A copy of the Cookies database is opened read-only with Node's node:sqlite, the 20,000 most recently used cookies are decrypted and set in persist:ta-browser; cookies of a session get 7 days so that they outlive a restart. Passwords and history are not read, and values never leave the main process. Chrome's app-bound encryption on Windows (v20, from Chrome 127) only Chrome can undo: those are counted and skipped, and need a sign-in on the site.
• Logs are in the system app log directory under serve.log; open it from the Help menu.
• Comes with Cua Driver (MIT, fixed version and SHA-256 in scripts/cua-driver.ts). When starting ta serve, point TA_CUA_DRIVER to it so the built-in extension ta-computer-use can use desktop applications in the background without separate installation. On macOS, Cua's signature and notarization are preserved (signIgnore), so authorization belongs to CuaDriver.app; Ta updates do not require re-authorization. macOS uses a universal binary CuaDriver.app (~88 MB), Windows includes cua-driver.exe and cursor theme apps (~42 MB), and Linux includes cua-driver, cursor theme apps, and Wayland accessibility extension (~63 MB). When reusing a ta serve started in the terminal, it doesn't know about this copy and uses your own installation.

Development

bun run build --filter=@celljs/ta   # first build apps/ta (from repo root)
cd apps/ta-desktop
bun run setup                       # download Electron (bun install doesn't run its install script) and Cua Driver (to vendor/)
bun run start
bun run test
bun run package                     # pack to release/, no installer
bun run package:mac                 # dmg and zip; ad hoc signing if no CSC_LINK

Performance

bun run package
DIR=$(mktemp -d); bun bench/fake-model.ts $DIR & 
bun bench/measure.ts $DIR release/mac-arm64/Ta.app/Contents/MacOS/Ta   # outputs JSON

Uses an isolated agent directory and fake model to measure cold startup (ta serve ready, UI input available), RSS and macOS physical memory (footprint) for each process after 15 seconds idle, CPU after 30 seconds idle, and CPU and memory peaks during one ~8-second streaming response (1500 increments). Three runs on M4 Pro on 2026-11-11:

Metric	Result
Cold startup	ta serve ready 0.86–0.96 s, UI input available 1.14–1.40 s
Idle memory (RSS total)	590–660 MB: main process ~172, renderer ~162, ta serve 124–142, GPU ~90, network ~43
Idle memory (footprint total)	360–635 MB, variation mainly in GPU process graphics memory
Idle CPU	~0.6–0.8% total (main process health check and task polling vs ta serve, split roughly equally)
Streaming response CPU	~11–12% total single-core: ta serve 7%, renderer 2.3%, GPU and main ~1% each

Known Limitations

• No automatic updates yet: requires release channels and code signing certificates.
• The bundled Cua Driver doesn't include cua-driver-uia.exe: its uiAccess (for windows running as administrator) requires installation in Program Files, but the installer is per-user. Windows and Linux installer packages have not been verified on real machines.
• Electron lacks browser's speech recognition service; voice input on the double is not available in the desktop app; speech synthesis works.