Multiple Chrome profiles

Let your coding agent pick the right Chrome profile

Your work account is in one Chrome profile. Your test account is in another. DevSnoop lets your agent list labeled profiles and target the tabs in the account you want to check, through one local HTTP endpoint.

Set up DevSnoop See the targeting commands

Set up each profile once

Install the Chrome extension in each profile you want the agent to use. Install the native host on the same machine using the installation guide.
Open each profile's DevSnoop popup. Enter an Agent profile label, such as Work or Test account, and click Save. Labels are optional; choose distinct names without personal or client details.
Keep those profiles open and connected. In each profile, activate a license or start the 24-hour preview. Grant the required site origin in that profile's popup when DevSnoop asks.

The standard installer supports macOS and Linux on ARM64 and x64. The agent must be able to make HTTP requests to 127.0.0.1:9400 on the same machine. A remote agent needs access to that local bridge; these examples assume local access.

Find the account before finding the tab

Call list_connections to see connected profiles and the current default.

bash

curl -s -X POST http://127.0.0.1:9400/ \
  -H 'Content-Type: application/json' \
  -d '{"command":"list_connections","params":{}}'

Generic example of the response's result, shortened to the targeting fields. All labels and IDs below are invented for this example.

json — result excerpt

{
  "selectedConnectionID": "native-123-example",
  "connections": [
    { "connectionID": "native-123-example",
      "profileID": "example-work-profile",
      "label": "Work", "selected": true },
    { "connectionID": "native-456-example",
      "profileID": "example-test-profile",
      "label": "Test account", "selected": false }
  ]
}

Use the returned connectionID for requests. The profileID identifies the extension installation in local storage; the connection ID can change when it reconnects. Labels can be empty or duplicated, so ask the user if the intended profile is unclear.

For a test-account check, replace native-456-example below with that profile's current connection ID. Check ping for its license or preview state, then list its tabs.

bash

# Check entitlement in the test profile first
curl -s -X POST http://127.0.0.1:9400/ \
  -H 'Content-Type: application/json' \
  -d '{"command":"ping","params":{},
       "connectionID":"native-456-example"}'

# Find the tab in that same profile
curl -s -X POST http://127.0.0.1:9400/ \
  -H 'Content-Type: application/json' \
  -d '{"command":"list_tabs","params":{},
       "connectionID":"native-456-example"}'

Replace 123 with the tab's id from that profile's list_tabs response. Keep both IDs on the page request.

bash

curl -s -X POST http://127.0.0.1:9400/ \
  -H 'Content-Type: application/json' \
  -d '{"command":"page_summary","params":{},
       "connectionID":"native-456-example","tabID":123}'

connectionID selects the profile; tabID selects a tab inside it. Omitting tabID uses the selected profile's active tab. Before clicking or filling anything, check that the page summary matches the intended account and page.

Choose a default, or target every request

select_connection changes the default for later commands that omit a top-level connectionID.

bash

curl -s -X POST http://127.0.0.1:9400/ \
  -H 'Content-Type: application/json' \
  -d '{"command":"select_connection",
       "params":{"connectionID":"native-456-example"}}'

The default is shared by callers using that broker. It stays in broker memory while the connection is available; it is not a saved preference across broker restarts. A per-request connectionID overrides the default without changing it.

When the selected connection disappears, the broker chooses an available connection as the default. An untargeted command could then use another profile. A request targeting an unknown connection returns an error instead of switching profiles.

For work and test accounts, send connectionID on every command, including ping and list_tabs. After a disconnect, list connections again and confirm the profile before continuing. Do not blindly retry an action whose outcome is unknown.

Permissions and limits

DevSnoop uses existing Chrome profiles and their signed-in accounts. It does not create an isolated browser or make a profile label an access restriction.
Page access is granted per origin in each profile. Selecting a profile does not grant a site permission. Tab listing can reveal that profile's tab URLs and titles; keep unrelated browser data out of agent responses and shared logs.
The native host listens on loopback. Its follower connections use a local authentication token, but the agent HTTP API does not require that token. Use trusted local callers and do not expose the port to a network.
Chrome's debugger permission is used for logs, network capture and screenshots. Chrome can show its debugging banner. Browser-internal pages such as chrome:// are not ordinary inspectable web pages.
Labels and profile IDs are stored in the profile's local extension storage and returned to local callers. DevSnoop returns page data locally; the agent you use may send that data to its own provider. See the privacy policy for license verification, analytics and diagnostics.

Continue with the command reference for inspection, interactions and debugging. The same targeting fields apply to those commands.