identify-chrome-devices

name	identify-chrome-devices
description	Identify and name Chrome instances connected to the Claude-in-Chrome extension under the current Claude account, and persist a stable deviceId -> name mapping to a local file outside the repo. Use when the user asks to "identify my chrome devices", "name my browsers", wants to disambiguate list_connected_browsers output, or invokes /identify-chrome-devices. Requires a session with the Claude-in-Chrome extension actually connected — see developer_docs/tools/claude-in-chrome-device-identification.md for background and the policy on preferring Playwright for ordinary browser automation.
user-invocable	true

Identify Chrome Devices

Automates the manual workaround from developer_docs/tools/claude-in-chrome-device-identification.md: loop through every deviceId the current Claude account can see, help the user confirm which physical device each one is, and record the result to a local mapping file — so this doesn't have to be done by hand in-chat every time a new device connects.

Before running this: confirm the task genuinely needs Claude-in-Chrome. For ordinary browser automation/testing, use Playwright (playwright-e2e skill) instead — it's cheaper and more flexible. This skill exists only because identifying a user's already-paired physical devices is something Playwright cannot do (it launches its own separate browser, with no visibility into paired Claude-in-Chrome devices).

Step 0 — Precondition check

Confirm list_connected_browsers, select_browser, and javascript_tool are actually available in this session (check the active tool list / deferred-tool search). If they aren't, this session isn't connected to the Claude-in-Chrome extension — tell the user this skill must be run from a session that has it connected, and stop here.

Use select_browser, not switch_browser, throughout this skill: select_browser(deviceId) targets a known device directly. switch_browser is a different tool — it broadcasts a pairing prompt to every connected device and waits for the user to manually click "Connect", and does not accept a deviceId to target one device. It has no role in this automated loop.

Step 1 — Load the existing mapping

Determine the local mapping file path for the current OS:

• Windows: C:\Credentials\claude-chrome-devices.json
• Linux/Mac: ~/.config/hmis/claude-chrome-devices.json

If it exists, read and parse it. If it doesn't exist yet, treat the map as empty — it will be created in Step 4. Never look for or write this file anywhere inside the project repo.

Step 2 — Enumerate connected devices

Call list_connected_browsers. For each returned deviceId, check it against the loaded map:

• Known (already has a name entry) → skip by default, no need to re-prompt. Exception: if the user asked to re-verify a specific device, or to re-verify everything (e.g. "re-check my devices"), include already-known devices in the work list too — that's the only path that reaches the lastConfirmed update in Step 3.
• Unknown → always add to the work list for Step 3.

If the work list is empty, report the existing mapping to the user (Step 5) and stop — nothing new to identify or re-verify.

Step 3 — Identify each unknown device

For each deviceId in the work list, in turn:

1. Call select_browser with that deviceId to make it the active device.
2. Open a tab and use javascript_tool to inject a full-viewport banner showing the raw deviceId as large, plain text on the page — nothing else needed on the page for this to work.
3. Use AskUserQuestion to ask the user to physically check that device's screen and confirm: is this the device they expect, and what name should it be given (e.g. "Home laptop", "Office desktop", "DC server 2")? Let them decline/skip a device if they don't recognize it right now.
4. If the user provided a name:
   • New device (wasn't in the loaded map): add an entry:

     {
       "deviceId": "<the deviceId>",
       "name": "<user-supplied name>",
       "osPlatform": "<from list_connected_browsers>",
       "isLocal": <from list_connected_browsers>,
       "identifiedUnderAccount": "<current Claude account, e.g. email>",
       "firstIdentified": "<today's date>",
       "lastConfirmed": "<today's date>"
     }
     

   • Already-known device being re-verified: update that entry's lastConfirmed (and name, if the user gave a different one) in place — never create a duplicate entry for a deviceId already in the map.

Step 4 — Persist the mapping

Before writing, re-read the local file — if it changed since Step 1 (e.g. another session identified devices in the meantime), merge those entries into the in-memory map first rather than silently discarding them.

Write the full updated {"devices": [...]} map as JSON to a temporary file in the same directory (creating the directory first if it doesn't exist), confirm it parses back as valid JSON, then rename it over the target file. This avoids leaving an unreadable half-written file if the write is interrupted.

Step 5 — Summarize

Print a deviceId -> name table for every device now in the mapping (known + newly identified this run) so the user has a single confirmation of the current state. Remind them the file lives at the OS-specific path above, outside the repo, and is never committed.

Note on multiple Claude accounts

list_connected_browsers only sees devices connected under the Claude account driving the current session. If the user has devices under more than one account, this skill needs to be run once per account — the same local mapping file accumulates entries across runs, with each entry's identifiedUnderAccount recording which account identified it. Anthropic's docs don't confirm deviceId is globally unique across accounts, so if the same deviceId shows up under two accounts with different names, flag it to the user rather than silently overwriting one with the other.