# What makes Inspect a great alternative to ios-webkit-debug-proxy
Source: https://docs.inspect.dev/alternatives/ios-webkit-debug-proxy
Inspect is more than [ios-webkit-debug-proxy](https://github.com/google/ios-webkit-debug-proxy), which provides the raw connection to the underlying WebKit Remote Debugging Protocol connection on the iOS device.
### How Inspect is different
Inspect includes a protocol mapping layer that makes it possible to
use the modern Chrome DevTools front-end with the webkit instance running in your iOS device.
Inspect builds upon the learnings from the ios-webkit-debug-proxy and RemoteDebug projects and packages all the necessary tools and protocol adaptors into one convenient app that enables
you to remote debug Safari on iOS from your Mac and Windows machine.
# What makes Inspect a great alternative to remotedebug-ios-webkit-adapter?
Source: https://docs.inspect.dev/alternatives/remotedebug-ios-webkit-adapter
Inspect is the spiritual successor to
[remotedebug-ios-webkit-adapter](https://github.com/RemoteDebug/remotedebug-ios-webkit-adapter), which was created back in 2016 by myself for earlier versions of iOS, and doesn't work with modern iOS versions.
### How Inspect is different
Inspect includes a protocol mapping layer that makes it possible to
use the modern Chrome DevTools front-end with the webkit instance running in your iOS device.
Inspect builds upon the learnings from the ios-webkit-debug-proxy and RemoteDebug projects and packages all the necessary tools and protocol adaptors into one convenient app that enables you to remote debug Safari on iOS from your Mac and Windows machine.
# Inspect.dev API documentation and OpenAPI
Source: https://docs.inspect.dev/developers/api
Official Inspect.dev HTTP API documentation, OpenAPI 3.1 specification, versioning, errors, pagination, rate limits, and agent resources.
The official Inspect.dev HTTP API supports release discovery, explicit CLI
feedback, OAuth compatibility, account subscriptions, and billing. Mobile
browser debugging itself runs locally through the
[Inspect CLI](https://inspect.dev/products/cli).
## Machine-readable Inspect API contract
* [Inspect OpenAPI 3.1 specification](https://inspect.dev/openapi.json)
* [Inspect API agent context](https://inspect.dev/api/llms.txt)
* [Inspect API catalog](https://inspect.dev/.well-known/api-catalog)
* [Inspect API discovery response](https://inspect.dev/api)
## Inspect API conventions
* Send `Inspect-Version: 2026-08-06`, or omit it to use the current version.
* Errors use stable `code`, `message`, and recovery `hint` fields.
* List endpoints use opaque cursors and return next-page state.
* Responses advertise rate limits; HTTP 429 includes `Retry-After`.
* Retriable billing writes accept `Idempotency-Key`.
## Submit Inspect CLI feedback
`POST https://inspect.dev/api/feedback` accepts explicit, user-authored
feedback from an authenticated Inspect user. Send the OAuth access token as a
Bearer `Authorization` header. The required JSON object contains:
* `id`: a caller-generated UUID. It is returned as the receipt and used to
deduplicate delivery; reuse it when retrying the same submission.
* `message`: the feedback text, from 1 to 4000 characters after trimming.
* `category`: `bug`, `idea`, `friction`, or `other`.
* `cliVersion`, `platform`, `arch`, and `nodeVersion`: basic CLI/runtime
metadata strings from 1 to 128 characters each.
A successful response is `{ "received": true, "id": "" }`. Invalid
JSON or fields return HTTP 400, delivery failures return HTTP 500, and clients
are limited to five submissions per authenticated user every 60 seconds. HTTP 429 includes
`Retry-After`.
The service derives the Clerk user ID from the validated bearer token and ties
the delivered feedback to that account; a client-supplied user ID is rejected.
The command sends only the generated receipt ID, explicit message, category,
and listed CLI/runtime metadata in the JSON body. It does not attach logs,
URLs, device or target identifiers, command history, or the working directory.
Missing or invalid credentials return HTTP 401.
## Authentication
Inspect uses OAuth 2.0 Authorization Code with PKCE through Clerk. See the
[Inspect authentication documentation](/developers/authentication) and
[least-privilege permission matrix](/developers/permissions).
Use the CLI for local device and browser actions. Do not invent cloud API
endpoints for snapshots, console messages, network requests, or screenshots.
# Inspect.dev authentication and OAuth documentation
Source: https://docs.inspect.dev/developers/authentication
Official Inspect.dev authentication documentation for OAuth 2.0 with PKCE, supported scopes, protected-resource discovery, and errors.
Official Inspect.dev account access uses OAuth 2.0 Authorization Code with PKCE through
Clerk. The free CLI workflow does not require authentication, and Inspect does
not issue broad API keys, shared passwords, or unattended machine credentials.
## OAuth discovery
Inspect is the protected resource at `https://inspect.dev`. Its
[RFC 9728 protected-resource metadata](https://inspect.dev/.well-known/oauth-protected-resource)
identifies `https://clerk.inspect.dev` as the authorization server.
Clerk publishes authorization-server and OpenID Connect metadata at:
* `https://clerk.inspect.dev/.well-known/oauth-authorization-server`
* `https://clerk.inspect.dev/.well-known/openid-configuration`
## Sign in with the Inspect CLI
1. Run `inspect login`.
2. The CLI creates a PKCE verifier and challenge and opens the authorization page.
3. A human approves the browser flow.
4. Verify the session with `inspect account --json`.
Agents may start the login flow, but must never ask a user to paste a password,
access token, or other credential into a conversation.
## Scopes and permissions
Supported scopes include `openid`, `profile`, `email`, `offline_access`, and
`user:org:read`. Request only the scopes needed for the current task. See the
[Inspect permission matrix](/developers/permissions) for the
endpoint-to-scope mapping.
## Authentication errors
Missing, expired, or invalid credentials return HTTP 401 with a structured
Inspect error and a `WWW-Authenticate` discovery hint. Valid credentials
without sufficient permission return HTTP 403. Follow the response `hint` and
retry only when the operation is safe.
Append `.md` to this page URL for a low-overhead Markdown version of the guide.
# Inspect.dev developer resources
Source: https://docs.inspect.dev/developers/index
Official Inspect.dev developer resources for API documentation, OpenAPI, OAuth authentication, MCP, webhooks, the CLI, and coding agents.
Build with and automate Inspect.dev using these official human- and
machine-readable developer resources. The stable primary-domain directory is
also available as [HTML](https://inspect.dev/developers) and
[Markdown](https://inspect.dev/developers.md).
HTTP API documentation, OpenAPI 3.1, versioning, errors, and agent context.
OAuth 2.0 with PKCE, supported scopes, discovery metadata, and errors.
Search the Inspect docs over MCP or connect MCP agents to a mobile browser.
Current webhook availability and the signed Stripe receiver contract.
## Inspect CLI and agent resources
* [Inspect CLI documentation](https://inspect.dev/products/cli)
* [Official Inspect CLI package on npm](https://www.npmjs.com/package/@inspectdotdev/cli)
* [Official Inspect source repository](https://github.com/inspectdev/inspect)
* [Inspect coding-agent setup](https://inspect.dev/agent.md)
* [Inspect Agent Skills index](https://inspect.dev/.well-known/agent-skills/index.json)
* [Inspect AI Catalog](https://inspect.dev/.well-known/ai-catalog.json)
* [Inspect agent-readable navigation](https://inspect.dev/llms.txt)
Mobile browser debugging runs locally through the Inspect CLI. The HTTP API
covers release discovery, authenticated CLI feedback, OAuth compatibility,
subscriptions, and billing; it does not proxy a connected phone or simulator
through a cloud device farm.
# Inspect.dev MCP server and mobile debugging integrations
Source: https://docs.inspect.dev/developers/mcp
Official Inspect.dev MCP documentation for the docs server and connecting coding agents to mobile browsers through Chrome DevTools Protocol.
Inspect.dev supports two distinct MCP workflows: searching the documentation and
debugging a live mobile browser.
## Inspect documentation MCP server
The read-only documentation MCP server searches and retrieves Inspect guides.
It uses Streamable HTTP and requires no authentication.
```json theme={null}
{
"mcpServers": {
"inspect-docs": {
"url": "https://docs.inspect.dev/mcp"
}
}
}
```
* Server URL: `https://docs.inspect.dev/mcp`
* [Inspect MCP server card](https://docs.inspect.dev/.well-known/mcp/server-card.json)
* Tools: documentation search and read-only documentation filesystem queries
## Debug mobile browsers from MCP agents
Device actions run locally through the
[Inspect CLI](https://inspect.dev/products/cli). Inspect exposes a Chrome
DevTools Protocol endpoint for the connected mobile browser, so Chrome DevTools
MCP, Puppeteer, and other CDP-compatible clients can use the live device.
This keeps USB devices and local development servers on the user's machine
instead of sending them to a remote Inspect service.
```bash theme={null}
inspect cdp --json
npx chrome-devtools-mcp@1.6.0 \
--browser-url=http://127.0.0.1:9222
```
## iOS/WebKit capability matrix
Chrome DevTools MCP exposes Chromium-shaped tools. Inspect implements the
parts that have an honest WebKit translation or simulator host assist and
returns explicit errors for Chromium-only behavior.
| Capability | Support on iOS through Inspect |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| Pages: list and select | Supported |
| Close page | No truthful WebKit host equivalent; the client reports when the last page remains open |
| Navigation and new page | Supported; missing WebKit navigation falls back to `location.assign`, and simulator tab creation uses `simctl openurl` |
| Snapshot, evaluate, console, network, screenshot, wait | Supported |
| Click, hover, fill, form fill, typing, keys | Synthetic DOM input; printable text errors if no editable control is focused |
| File upload | Supported where WebKit exposes or Inspect synthesizes the file input node |
| Viewport resize | Unsupported on Cocoa WebKit; use the intended simulator/device size |
| Media emulation | Partial; supported only where WebKit exposes a truthful page preference or media override |
| Performance trace and insights | Translated from WebKit Timeline; version-sensitive and should be checked in the tool response |
| CPU/network throttling | Unsupported when WebKit has no truthful equivalent; never silently acknowledged |
| Heap snapshot | Supported through validated JavaScriptCore-to-CDP graph conversion; allocation timelines and sampling remain unavailable |
| CSS editing | Supported through stylesheet, rule, and inline-style translations |
| JavaScript live editing | Unsupported; WebKit has no `Debugger.setScriptSource` equivalent and Inspect reports no change |
| SharedWorker debugging | Upstream-blocked; WebKit exposes neither a debuggable target nor a remote-inspector message channel |
| Lighthouse | Best effort; individual Chromium-only audits may be unavailable |
MCP transports sometimes return a failed tool call as ordinary text with
`isError: false`. Treat responses containing an explicit failure such as
“Unable to”, “was not found”, or “unsupported” as failures. Inspect's pinned
coverage sweep enforces that rule and checks the exact 29-tool inventory of
`chrome-devtools-mcp@1.6.0`.
* [Inspect coding-agent setup](https://inspect.dev/agent.md)
* [Chrome DevTools MCP](https://github.com/ChromeDevTools/chrome-devtools-mcp)
* [Inspect API documentation](/developers/api)
# Inspect.dev OAuth permissions and scopes
Source: https://docs.inspect.dev/developers/permissions
Official Inspect.dev OAuth scopes and API endpoint permissions for developers and coding agents, with least-privilege guidance.
Inspect.dev uses Clerk OAuth 2.0 Authorization Code with PKCE. Request only the
scopes required for the current operation. The free CLI workflow and public
changelog API require no authentication; submitting CLI feedback requires a
signed-in Inspect user.
## Scope matrix
| Scope | Permission | Used by |
| ---------------- | ---------------------------------------------------------- | ---------------------------------------------- |
| `openid` | Identify the signed-in user. | Feedback and authenticated API endpoints |
| `profile` | Read the user display name. | User, plan, and subscription endpoints |
| `email` | Read the account email address. | User, plan, and subscription endpoints |
| `offline_access` | Refresh a human-approved session. | Official CLI login |
| `user:org:read` | Read organization membership for team subscription access. | Organization-scoped plan and billing endpoints |
## Least-privilege rules
* Public discovery and changelog endpoints use no scopes.
* CLI feedback uses `openid` so the server can bind it to the verified user.
* Account reads use `openid profile email`.
* Request `user:org:read` only when the selected billing account is an organization.
* Billing operations require an authenticated human and explicit user approval.
## Discovery and errors
See the [Inspect authentication guide](/developers/authentication),
[OAuth protected-resource metadata](https://inspect.dev/.well-known/oauth-protected-resource),
and [Inspect OpenAPI specification](https://inspect.dev/openapi.json).
A missing or invalid credential returns HTTP 401 with a `WWW-Authenticate`
discovery hint. Valid credentials without sufficient permission return HTTP 403
as structured JSON.
# Inspect.dev webhook documentation
Source: https://docs.inspect.dev/developers/webhooks
Official Inspect.dev webhook behavior, Stripe signature verification, structured errors, and current outgoing-webhook availability.
Inspect.dev consumes signed Stripe events for subscription lifecycle updates. It
does not currently publish customer-configurable outgoing webhooks, so agents
must not invent a webhook registration or delivery API.
## Stripe webhook receiver
`POST https://inspect.dev/api/webhooks/stripe` is reserved for Stripe. Requests
must include a valid `Stripe-Signature` generated with the configured endpoint
secret. Unsigned or invalid requests are rejected before event processing.
Responses use the standard Inspect JSON error envelope with a machine-readable
code, message, and recovery hint. See the
[Inspect OpenAPI specification](https://inspect.dev/openapi.json) for the
request and response contract.
## Agent guidance
* Do not send test events to the production receiver.
* Do not ask a user to reveal a Stripe webhook secret.
* Use Stripe's signed delivery and retry behavior.
* Inspect the structured response before retrying.
* Contact [hello@inspect.dev](mailto:hello@inspect.dev) for a customer event-integration use case.
See the [Inspect API documentation](/developers/api) and
[authentication guide](/developers/authentication) for related contracts.
# How to debug mobile websites on Android devices with Inspect
Source: https://docs.inspect.dev/guides/android
Inspect allows you to debug Chrome and WebViews on Android devices from macOS, Linux, and Windows.
Here are the simple steps to follow whether you're testing or debugging an Chrome web page or app with Inspect:
## Step 1: Enable USB-debugging on your Android device
1. Open the Developer Options screen on your Android. See [Configure On-Device Developer](https://developer.android.com/studio/debug/dev-options.html) Options.
2. Select Enable USB Debugging.
## Step 2: Install ADB on your development machine.
1. Follow these instructions from [xda developers](https://www.xda-developers.com/install-adb-windows-macos-linux/) on how to install `adb`
2. Make ADB is discoverable in your \$PATH. You can validate this by running:
```
which adb
```
## Step 3: Connect your device and start Inspect
1. Connect your Android device directly to your development machine using a USB cable. Your Android device may ask you to confirm that you trust this computer.
2. Start Inspect
3. Your Android device should show up in the devices list.
Happy Inspecting!
# Android FAQ
### How does Android support work?
Inspect uses `adb` behind the scenes to detect and talk to your Android device. You need to have `adb` installed in your `$PATH` for Inspect to be able to execute commands to the devices.
Make sure you can start a terminal and run `adb devices` without problems.
### Which WebView types are supported on Android?
* Chrome
* Webview
* Crosswalk
# How to debug mobile websites on iOS devices with Inspect
Source: https://docs.inspect.dev/guides/ios
Inspect allows you to debug Safari on iOS devices from macOS, Linux, and Windows
Here are the simple steps to follow whether you're testing or debugging an iOS Safari web page or app with Inspect:
1. **Connect your iOS device to your PC via USB cable or Wi-Fi**. You can use any device with a macOS, Linux, or Windows operating system.
2. **Start Inspect** and follow the instructions on how to setup your computer.
3. You are good to go!
Happy Inspecting!
# iOS Simulator debugging
Source: https://docs.inspect.dev/guides/ios-simulator
How to debug Safari and WebViews running within the iOS Simulator with Inspect
Inspect can connect to your your iOS Simulator running locally on your Mac, so you can debug and inspect Safari and other targets without connecting a physical device.
### How to enable iOS Simulator debugging
1. Install XCode and install the iOS Simulator. See [https://developer.apple.com/documentation/xcode/installing-additional-simulator-runtimes](https://developer.apple.com/documentation/xcode/installing-additional-simulator-runtimes)
2. Install the XCode Commandline Tools. See [https://mac.install.guide/commandlinetools/](https://mac.install.guide/commandlinetools/)
3. Make sure `xcrun simctl` is installed and available in your `$PATH`. You can validate this by running
```
xcrun simctl help
```
1. Open Inspect.
2. Your iOS Simulator and its debuggable targets should now show up.
3. Happy Inspecting! 🎉
## iOS Simulator FAQ
### Inspect can't find my iOS Simulator on MacOS, what do to?
Inspect uses the `simctl` utility provided by Xcode to detect and interact with iOS simulators. Follow these guides to make sure `simctl` works correctly:
* [https://nshipster.com/simctl/](https://nshipster.com/simctl/)
* [https://medium.com/xcblog/simctl-control-ios-simulators-from-command-line-78b9006a20dc](https://medium.com/xcblog/simctl-control-ios-simulators-from-command-line-78b9006a20dc)
# How to debug WebViews on iOS devices with Inspect
Source: https://docs.inspect.dev/guides/ios-webviews
Inspect can only debug web content in developer provisioned applications or applications with the com.apple.webinspector.allow entitlement
### Which WebView types are supported on iOS?
* WKWebView
* WebView
* JSContext
This is a limitation from Apple, and something Inspect can't change. See [https://webkit.org/web-inspector/enabling-web-inspector/](https://webkit.org/web-inspector/enabling-web-inspector/) for details.
### How to get started?
Follow our [getting started guide](/installation) to get going.
## WebViews FAQ
### Enabling the Inspection of Web Content in Apps
In iOS 16.4 Apple made it possible for developers to control how WKWebView or JSContexts are inspectable via new `isInspectable` property. This means that if your app is using WebViews you probably need to set the `isInspectable` to true before Inspect can detect and debug your app.
Read [https://webkit.org/blog/13936/enabling-the-inspection-of-web-content-in-apps/](https://webkit.org/blog/13936/enabling-the-inspection-of-web-content-in-apps/) for more.
If you are building a ionic capacitor app, or cordova app please see:
* [https://github.com/ionic-team/capacitor/issues/6441](https://github.com/ionic-team/capacitor/issues/6441)
* [https://developer.apple.com/documentation/safari-developer-tools/enabling-inspecting-content-in-your-apps](https://developer.apple.com/documentation/safari-developer-tools/enabling-inspecting-content-in-your-apps)
# Wireless debugging over WiFi
Source: https://docs.inspect.dev/guides/ios-wifi
How to enable wireless wiifi debugging of Safari and WebViews with Inspect
Inspect can connect to your iOS devices over WiFi on macOS so you can remote debug and inspect Safari and other targets without any cables.
### How to enable wireless debugging
1. Open the Safari Preferences → Advanced and enable “Show Develop menu in menu bar" at the bottom.
2. Go how to the Develop menu bar in Safari → \ → Connect via Network in the menu.
3. Now you can unplug the cable and check whether Develop → Your device still shows up on the desktop Safari.
4. Close Safari.
5. Open Inspect, and your device should show up.
# How to debug network targets with Inspect
Source: https://docs.inspect.dev/guides/network-targets
Debug Chrome, Node.js, Electron, and other CDP-compatible applications over the network
Inspect can connect to any application that exposes the Chrome DevTools Protocol (CDP) over the network. This includes Chrome, Chromium-based browsers, Node.js, Electron, and other CDP-compatible runtimes.
## Enabling Network Targets
1. Go to **View → Devices → Enable Network Targets**
2. Network targets will appear in the sidebar under "Network Targets"
By default, Inspect connects to `localhost:9222`.
## Configuring Endpoints
You can configure custom endpoints by editing your Inspect config file:
| Platform | Config file location |
| -------- | ------------------------------------ |
| macOS | `~/.inspect/config.json` |
| Windows | `%USERPROFILE%\.inspect\config.json` |
Add your endpoints to the config file:
```json theme={null}
{
"devices": {
"enableNetworkTargets": true,
"networkTargets": [
"localhost:9222",
"192.168.1.100:9222",
"my-server.local:9229"
]
}
}
```
## Starting Debug Targets
### Chrome / Chromium
Start Chrome with remote debugging enabled:
```bash theme={null}
# macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222
# Windows
chrome.exe --remote-debugging-port=9222
# Linux
google-chrome --remote-debugging-port=9222
```
### Node.js
Start your Node.js application with the inspector:
```bash theme={null}
node --inspect=9229 app.js
```
To break on the first line of your application:
```bash theme={null}
node --inspect-brk=9229 app.js
```
### Electron
Start your Electron app with remote debugging:
```bash theme={null}
electron --remote-debugging-port=9222 .
```
## Context Menu Options
Right-click on targets in the sidebar for additional options:
* **Reload** - Refresh the active page
* **Bring to focus** - Activate the tab in the browser
* **Close tab** - Close the browser tab
* **Open new tab** - Open a new tab (right-click on the app name)
## Troubleshooting
### Target not appearing?
* Verify the application is running with debugging enabled
* Check the port number matches your config
* Ensure no firewall is blocking the connection
### Connection refused?
The debug port may be bound to localhost only. For remote debugging, start Chrome with:
```bash theme={null}
chrome.exe --remote-debugging-port=9222 --remote-debugging-address=0.0.0.0
```
Binding to `0.0.0.0` exposes the debug port to your network. Only do this on trusted networks.
### "Target already connected" error?
Only one debugger can connect to a target at a time. Close other DevTools windows or debuggers before connecting with Inspect.
# React DevTools
Source: https://docs.inspect.dev/guides/react-devtools
Debug React components on iOS and Android devices
**Prerequisite** You should have installed Inspect first.
Inspect includes React DevTools, allowing you to debug React components directly on iOS and Android devices. This brings the same powerful React debugging experience from desktop browsers to mobile.
## Features
React DevTools in Inspect provides the following capabilities:
* **Component Tree**: Browse the complete React component hierarchy on your device
* **Props & State**: Inspect and modify props and state in real-time
* **Hooks Inspector**: Debug useState, useEffect, useContext, and custom hooks
* **Component Search**: Locate components by name instantly
* **Highlight Updates**: Visualize which components are re-rendering
## Getting Started
1. **Connect your device** via USB (iOS or Android)
2. **Open your React app** in Safari (iOS) or Chrome (Android)
3. **Start debugging** - the React DevTools tab appears automatically
No additional configuration is required. When Inspect detects a React-based application, the DevTools tab becomes available automatically.
## Supported Platforms
React DevTools works with any React-based application running in a mobile browser or WebView, including:
* React Native Web applications
* Ionic apps with React
* Capacitor hybrid apps
* Progressive Web Apps (PWAs) built with React
# Installation guide
Source: https://docs.inspect.dev/installation
Start debugging the mobile web in under 5 minutes with Inspect
To get started with Inspect follow the steps below.
## Installation
1. Sign up to get an account on [http://inspect.dev](http://inspect.dev)
2. Download Inspect for your desktop on [http://inspect.dev/download](http://inspect.dev/download)
3. Follow the instructions in the Inspect app to get connected to your device.
4. 🎉
## Supported Platforms
Inspect works on macOS and Windows, and uses the official iOS drivers provided by Apple through iTunes.
We have experimental support for Linux, which relies on the open source project [libimobiledevice](https://libimobiledevice.org) that you need to install separately.
# Introduction to Inspect
Source: https://docs.inspect.dev/introduction
Get an overview of Inspect's features, and how to use them.
Installation guide
Using Inspect
Debug Safari on iOS with Inspect
Debug Chrome on Android with Inspect
## Help us make Inspect better
Did we miss something? Should we add a new section? Tell us at [hello@inspect.dev](mailto:hello@inspect.dev)
# Inspect CLI for coding agents
Source: https://docs.inspect.dev/products/cli
Set up Inspect CLI and debug iOS Safari, Android Chrome, and WebViews with typed commands, raw CDP, or Chrome DevTools MCP.
Inspect CLI gives coding agents direct access to mobile browsers on physical
devices and iOS simulators. The canonical, copy-pasteable setup guide is
[inspect.dev/agent.md](https://inspect.dev/agent.md). Once installed, prefer
`inspect agent-context` and `inspect skills get mobile-debugging`: both are
generated from the installed CLI version and cannot drift from its commands.
## Install and preflight
```bash theme={null}
npm install -g @inspectdotdev/cli@latest
inspect --version
inspect status --json
inspect agent-context
```
The simulator-provisioning workflow below requires CLI 3.2.0 or newer. If
`inspect devices create` is absent, the registry has not supplied that release
yet: use an existing simulator or update the CLI before continuing. Do not mix
the foreground `inspect` server with typed commands on the same ports; typed
commands start and reuse their own daemon automatically.
Every command supports `--json`. Successful and failed responses use stable
`{ok, command, data | error}` envelopes, and errors include recovery
suggestions and meaningful exit codes.
## Zero-hardware iOS quickstart (macOS)
```bash theme={null}
inspect devices create "Inspect iPhone" "iPhone 17 Pro" --json
inspect devices boot --json
inspect devices list --json
inspect open http://localhost:3000 --json
inspect snapshot --interactive --json
inspect screenshot --json
```
The optional third `devices create` argument accepts an installed runtime name,
version, or identifier—for example `"iOS 26.5"`, `"26.5"`, or
`com.apple.CoreSimulator.SimRuntime.iOS-26-5`. Omit it to let Xcode choose the
newest compatible runtime. Simulator creation requires macOS and Xcode.
## Physical devices
* iPhone/iPad: connect over USB, unlock, trust the computer, and enable
Settings → Safari → Advanced → Web Inspector.
* Android: enable Developer options and USB debugging, then accept the ADB
authorization prompt.
* Run `inspect devices list --json`. If the device is absent or not `ready`,
run `inspect doctor --json` and follow its suggestions.
## Agent debugging loop
```bash theme={null}
inspect open --json
inspect snapshot --interactive --json
inspect console list --types error,exception --json
inspect network list --failed --json
# edit the project
inspect reload --json
inspect console list --after --json
inspect screenshot --json
```
Use `--session ` to keep an agent's selected device, target, snapshot
references, and evidence checkpoints separate from other concurrent tasks.
`inspect devtools` opens Chrome DevTools for a human handoff without changing
the command workflow.
## Raw CDP and Chrome DevTools MCP
```bash theme={null}
inspect cdp --json
npx chrome-devtools-mcp@1.6.0 \
--browser-url=http://127.0.0.1:9222
```
`inspect cdp` returns browser and page WebSocket URLs for custom CDP scripts.
See [MCP integrations](/developers/mcp) for the supported iOS/WebKit capability
matrix. Inspect returns explicit unsupported-capability errors where Chromium
features have no honest WebKit or host equivalent; callers must not treat error
text returned as MCP content as success.
## Attach VS Code to mobile Safari
An agent can get the complete, version-matched setup playbook directly from
the installed CLI:
```bash theme={null}
inspect skills get vscode-debugging
```
It covers merging existing VS Code configuration, starting the CLI, source
maps, and verifying source loading and breakpoints. Both `inspect agent-context`
and `inspect cdp` point agents to this playbook.
Open the page in Safari on your connected iPhone, iPad, or iOS simulator. With
the Inspect CLI installed and available on your PATH, add this configuration
to your project's `.vscode/launch.json`:
```json theme={null}
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to Safari (Inspect)",
"type": "chrome",
"request": "attach",
"preLaunchTask": "Start Inspect CDP",
"address": "127.0.0.1",
"port": 9222,
"webRoot": "${workspaceFolder}",
"timeout": 30000
}
]
}
```
Add the matching task to `.vscode/tasks.json`:
```json theme={null}
{
"version": "2.0.0",
"tasks": [
{
"label": "Start Inspect CDP",
"type": "shell",
"command": "inspect",
"args": ["cdp", "--json"],
"problemMatcher": []
}
]
}
```
Select **Attach to Safari (Inspect)** in Run and Debug and press **F5**. The task
starts or reuses the Inspect daemon, then exits so VS Code can attach. It does
not need a background-task matcher. The daemon stays available after you stop
debugging; run `inspect stop` when you want to shut it down.
Use the port reported by `inspect cdp` if you configured a different one. Add
`"urlFilter": "https://your-app.example/*"` to select a particular page when
multiple targets are available. VS Code connects directly to Inspect's browser
endpoint; no compatibility proxy is needed.
Let VS Code attach to the page: running `inspect targets use auto` beforehand
can occupy Safari's single Web Inspector connection. If another client already
owns it, stop that debug session or close its inspector. For a CLI session you
previously selected, `inspect stop` releases it; press **F5** again to start
Inspect and attach VS Code.
**Loaded Scripts** should show the page's JavaScript. Breakpoints in workspace
TypeScript require the deployed page to serve matching source maps. Without
source maps, set breakpoints in generated JavaScript under Loaded Scripts.
CLI 3.3.0 lacks the `Target.attachToBrowserTarget` handshake required by VS Code.
This setup requires a build containing browser-session support. If that method
returns an unsupported error, update Inspect before retrying.
## Current access model
Login is optional for the free tier. Every debugging capability is available
inside two free 15-minute sessions per day; device discovery, simulator
provisioning, target listing, diagnostics, status, and account commands never
open a session. `SUBSCRIPTION_REQUIRED` reports why access stopped and when a
new free session becomes available. Run `inspect upgrade --json` only when the
user wants a checkout link. Sending product feedback is the exception: it
requires `inspect login` so the report can be tied to a real Inspect user.
## Send feedback from an agent
If Inspect itself behaves incorrectly, is confusing, or is missing a useful
capability, a signed-in agent can send a concise report without starting the
daemon or opening a debug session:
```bash theme={null}
inspect login
inspect feedback "Snapshot refs need clearer recovery guidance" \
--category friction --json
```
Use `bug`, `idea`, `friction`, or `other` (the default). A successful response
contains a receipt ID and means the feedback service accepted the message; a
delivery failure returns a nonzero, retryable error instead of a false success.
The explicit submission works with `--no-telemetry` and includes only the
authored message, category, a generated receipt ID, the server-verified Inspect
user ID, and basic CLI/runtime metadata. Inspect does not attach logs, page
data, device identifiers, URLs, working-directory paths, or command history.
The service derives the user ID from the OAuth bearer token; the token is never
included in the body. Do not include secrets. This command is for feedback
about Inspect, not for reporting a bug in the website being debugged.
## Recovery
* No devices: `inspect doctor --json`.
* No targets: `inspect launch safari --url --json`.
* Upgrade/daemon mismatch: rerun the command; the CLI follows the daemon
sidecar and replaces an older daemon automatically. If a foreground server
owns the ports, stop that server first.
* Stale snapshot ref: rerun `inspect snapshot --interactive --json` and use the
new `@eN` reference.
* Need the exact installed contract: `inspect agent-context`.
# Managing teams and organizations
Source: https://docs.inspect.dev/settings/organizations
You can create your own organization to manage multiple accounts under one subscription.
## How to create a team
1. Go to [https://inspect.dev/account/organizations](https://inspect.dev/account/organizations)
2. Click the `Create Organization` button
## Manage your organization
1. Go to [https://inspect.dev/account/organizations](https://inspect.dev/account/organizations)
2. Choose your organization.
3. Use the organizations page to add/remove members, settings and billing.
## Organization Billing
To use organizations you have to subscribe to our `Inspect Teams` plan. We don't charge for single member organizations.
You manage your organization's billing details on Stripe.
# Billing
Source: https://docs.inspect.dev/troubleshooting/billing
We put together a list of the most frequently asked billing questions
### Inspect says my subscription has expired
Inspect is using your `email` to identify your subscription, so if you used two different emails for your account and another when buying subscription things may have become out of sync.
Please contact `hello@inspect.dev` and we'll fix things for you.
# Devices and targets
Source: https://docs.inspect.dev/troubleshooting/devices-targets
Here's a quick FAQ for common problems with devices and target detection when trying to use Inspect.
### Can Inspect debug Google Chrome or Microsoft Edge on iOS?
Yes, Inspect can debug `Google Chrome` on iOS.
Read our detailed guide here: [https://inspect.dev/guides/debug-chrome-ios](https://inspect.dev/guides/debug-chrome-ios)
At the moment we do not support debuggig of `Microsoft Edge` on iOS.
### Inspect can't find my Safari tabs, what to do?
Sometimes Inspect can have trouble finding the Safari tabs on your iOS device.
The following steps unblock 80% of our users:
1. Did you restart your iOS device after enabling Web Inspector?
2. If you are using Windows, did you install and start iTunes to make sure your iOS device is paired with your computer?
3. Make sure your iPhone is unlocked.
4. Make sure Safari or the app you are trying to debug is the active one
As ironic as it might sound, but some users have needed to **restart** their Windows machine after installing iTunes. We suspect this is to start the Apple Driver provided by iTunes as a Windows service.
If your issue persists, please contact support and we are more than happy to help.
### **Inspect on Windows can see my device, but it says "no targets found.”**
This typically happens if you just enabled `web inspector` on your iOS device. Please try to force restart Safari or restart your iOS device to make sure the web inspector service is running on your device.
**Sometimes it helps to:**
* Disconnect my phone
* Restart iTunes
* Connect your phone again.
### Inspect doesn't detect my app using WebViews, what to do?
Inspect can only debug developer-provisioned apps.
This means that the app needs to have been installed via Xcode, and not via the AppStore or TestFlight.
This is a limitation from Apple. See [https://webkit.org/web-inspector/enabling-web-inspector/](https://webkit.org/web-inspector/enabling-web-inspector/) for details.
# FAQ
Source: https://docs.inspect.dev/troubleshooting/faq
We put together a list of the most frequently asked questions
### How do I debug my local site with Inspect?
iOS Web Inspector does not expose Android-style reverse port forwarding, so a
physical device cannot transparently reach a server on your computer through
`http://localhost`. Use a network-reachable HTTPS development URL or a secure
tunnel such as [ngrok](https://ngrok.com/).
Inspect is researching an opt-in HTTP-only bridge, but it would not replace
transparent forwarding for WebSockets, streaming responses, or arbitrary TCP
services.
### Can Inspect emulate a different iOS viewport size?
No. WebKit compiles its screen-size override out on Apple platforms, so Inspect
cannot change the real CSS viewport or media-query result of an iOS Safari or
WebView target. Test with the intended simulator/device size, or use Safari's
Responsive Design Mode on macOS for approximate layout work.
### Can I edit source code while debugging?
CSS stylesheet, rule, and inline-style editing is supported. Live JavaScript
editing is not: the iOS Web Inspector protocol has no equivalent of Chrome's
`Debugger.setScriptSource`. Inspect reports that limitation without claiming
the script changed.
### Can Inspect throttle an iOS target's network?
Not through Web Inspector. iOS does not enable WebKit's inspector-level
throttling primitive. For device-wide testing, use Apple's Network Link
Conditioner from the device's Developer settings.
### Can Inspect debug SharedWorkers on iOS?
Not currently. WebKit does not expose a debuggable SharedWorker target or a
working remote-inspector message channel. Inspect can add the target mapping
only after WebKit exposes that channel.
### Windows Defender gives me a warning when opening Inspect?
Windows 10 gives a warning about Inspect because the `Smart Scanner filter` hasn't seen more than `1000 users using` Inspect before.
Details in
* [https://answers.microsoft.com/en-us/protect/forum/protect\_defender-protect\_scanning-windows\_10/windows-defender-is-giving-a-warning-when/ee48147e-8fe2-46d5-bfba-](https://answers.microsoft.com/en-us/protect/forum/protect_defender-protect_scanning-windows_10/windows-defender-is-giving-a-warning-when/ee48147e-8fe2-46d5-bfba-)
* [https://security.stackexchange.com/questions/139347/smart-screen-filter-still-complains-despite-i-signed-the-executable-why](https://security.stackexchange.com/questions/139347/smart-screen-filter-still-complains-despite-i-signed-the-executable-why)
### Proxy server support
Inspect is built with Electron, and has exactly the same proxy server support as Google Chromium.
Here's a snippet from [Chromium's documentation](https://www.chromium.org/developers/design-documents/network-settings/):
"The Chromium network stack uses the system network settings so that users and administrators can control the network settings of all applications easily. The network settings include:
```
- proxy settings
- SSL/TLS settings
- certificate revocation check settings
- certificate and private key stores"
```
This means that your proxy settings should be picked up automatically.
Otherwise, you can use the following command-line arguments to control your proxy settings:
```
# Disable proxy
--no-proxy-server
# Manual proxy address
--proxy-server==[:][;...] | [:] | "direct://"
# Manual PAC address
--proxy-pac-url=
# Disable proxy per host
--proxy-bypass-list=(|)[:][;...]
```
To learn more about these command-line arguments, see [Chromium Network Settings](https://www.chromium.org/developers/design-documents/network-settings/).
# Issues and bugs
Source: https://docs.inspect.dev/troubleshooting/issues-bugs
We run a transparent issue tracker, take a peak and file issues
## GitHub
We have a public bug tracker on GitHub. [https://github.com/inspectdev/inspect-issues/issues](https://github.com/inspectdev/inspect-issues/issues)
# Roadmap
Source: https://docs.inspect.dev/troubleshooting/roadmap
Follow our roadmap and suggest new features
## Public Roadmap
You can see the Roadmap for Inspect on GitHub, [https://github.com/inspectdev/inspect-issues/projects/1](https://github.com/inspectdev/inspect-issues/projects/1)
# Support
Source: https://docs.inspect.dev/troubleshooting/support
We provide support for subscriptions of Inspect
## How to contact us?
Please contact us on [https://inspect.dev](https://inspect.dev) or via [hello@inspect.dev](mailto:hello@inspect.dev).
# Using Inspect
Source: https://docs.inspect.dev/using-inspect
Learn how to use Inspect
**Prerequisite** You should have installed Inspect first.
Inspect is using the Chrome DevTools front-end to give you the industry-leading UI for iOS web debugging.
## Docs
You can use the [Chrome DevTools docs](https://developer.chrome.com/docs/devtools/overview/) or watch this video below to learn about the features in DevTools and how to use them.
## Videos