Handle SPA-heavy apps
Use Sidekar more effectively on apps like Gmail and Google Docs where the interface keeps shifting inside a long-lived client-side shell.
In-page control for SPA-heavy sites.
The Sidekar Chrome extension adds an in-page bridge for apps like Gmail and Google Docs that push past plain browser automation. Use it for the harder cases, not as the default path for every site.
01
Install Sidekar
Run curl -fsSL https://sidekar.dev/install | sh. The installer also unpacks the extension into ~/.sidekar/extension.
02
Sign in the CLI
Run sidekar device login. The Sidekar daemon then tells sidekar.dev which local port it listens on, so the extension can find it.
03
Load the extension in Chrome
Open chrome://extensions, turn on Developer mode, click Load unpacked and select ~/.sidekar/extension. The extension is not in the Chrome Web Store yet.
04
Sign in from the popup
Click the Sidekar icon in the toolbar, then Sign in. Use the same sidekar.dev account as the CLI, with GitHub or Google.
05
Use sidekar browser ext
sidekar browser ext status shows the connection. sidekar browser ext tabs lists the tabs of your normal Chrome profile.
sidekar update writes the new version of the extension into the same folder. Click reload on the Sidekar card in chrome://extensions to use it. If the folder is gone, sidekar browser ext dev-extract writes it again.
Why the extension exists
CDP is enough for a lot of browser automation. The extension is for the cases where an in-page bridge is more reliable: rich editors, dense client-side UIs, and apps that keep most of their behavior inside the page.
Keep local control
The extension talks to a local bridge on 127.0.0.1. It is not a hosted browser service.
Use your signed-in browser state
Work inside the browser you already use instead of recreating cookies, sessions, and app state in a separate automation environment.
Keep CDP as the default
The extension is an extra layer for specific sites. Most browser work should still run through Sidekar’s normal browser commands.
Why it needs broad access
Agents may need to act on any page you direct them to, so the extension asks for access to all sites, your tabs, history and the debugger.
Local connection
The extension connects to the Sidekar daemon over a WebSocket on 127.0.0.1. The daemon must be running and signed in with sidekar device login.
Host permissions
Needed because the agent may need to automate any site you choose. Clicks, typing, reads and screenshots happen only when a local Sidekar command asks for them. The debugger permission is for real key events and paste in editors like Google Docs.
Network recording
While it is connected, the extension records each page's fetch, XHR and event-stream requests, with auth headers and token-like values masked. It sends them only to the daemon on your machine. The daemon keeps the latest 2,000 per browser profile in memory, for sidekar browser network passive to read. sidekar browser network passive emit-off mutes it on the pages that are open now.
Local-first data path
Page reads, clicks, typing, and screenshots are driven from your local machine. The website is for auth, dashboards, and account-level services.
What people will ask first
This page covers the first questions people ask before they trust a local browser bridge.
Does the extension send my browsing data to Sidekar servers?
No. Page contents and network records go only to the Sidekar daemon on your machine. The extension contacts sidekar.dev for two things: to sign in, and to look up the local port of your daemon.
Why do I need both CLI login and extension sign-in?
The CLI login identifies the local Sidekar device. The extension sign-in identifies the browser user. When the extension connects, the daemon asks sidekar.dev to check that both sign-ins belong to the same account, and refuses the extension if they do not.
What happens if I do not install the extension?
Sidekar still supports browser automation through direct CDP. Skip the extension unless the site really benefits from the in-page bridge.