The developer inspector

The developer inspector attaches Chrome DevTools to a running DataMind Oda app, so you can debug its host process and its connected browser clients from one DevTools window. It is development tooling for a checkout, not part of the everyday app, and it listens on this computer only.

For running, approving, stopping and removing dynamic packages, see Dynamic packages.

Turn the inspector on

The inspector joins one run through an overlay file; nothing is installed into your profile.

Build the project if you have not already: pnpm run build. The overlay loads the inspector from the build output.
Start the web mode with the overlay: oda --profile web --patch ./packages/experimental/inspector/cordis.patch.yml
Open the devtools:// address the app logs once the inspector listens. Chrome DevTools attaches to the run and opens on the Elements panel.

From a source checkout, pnpm run demo:inspector starts the same web mode with a source overlay instead of the built one.

What it serves

Once it listens, the inspector serves these addresses on one local port:

Address	What it answers
`/json`, `/json/list`	The DevTools discovery documents.
`/json/version`	The version document for the protocol.
`/devtools/page/<id>`	The target socket DevTools attaches to.
`/ingest`	The socket a browser client connects to.

A browser client joins as a source over the ingest socket, keeps its buffered observations across reconnects, and sends them in bounded frames and queues.

What you can inspect

Console merges entries from the host and every connected client; uncaught exceptions are delivered separately.
Sources lists the host's scripts. For a connected client, only the inspector's own bundle is catalogued; other page scripts are not listed.
Network records the host's fetch calls with the full URL, all request and response headers, bodies, status, timing, errors and cancellation. Bodies are kept as a prefix and marked truncated at the configured limits, and an aborted request keeps the bytes captured so far.
Runtime evaluates code in the host, or in a client you select; that selection routes evaluation, property access, function calls, promise awaiting and object release to the browser client.
Debugger serves the host: host breakpoints, pause and resume work, and console evaluation stays available while the host is paused. Client-script breakpoints, stepping and call frames are refused, and pause and resume never control a client.
Elements shows the extension runtime as one tree: a fixed <host> container, and a <clients> container with one <client> entry per connected client. The tree loads level by level, and levels you expand load on demand.
A custom inspector domain on the same connection turns its change notifications on and off, lists the connected sources, and reads the tree. The tree read needs no DevTools session and enables no other domain.

Defaults you can change

These are the inspector's fields, with their defaults. Set a field in the inspector's entry in your overlay when a default does not fit the run:

Field	Default	Meaning
`host`	`127.0.0.1`	The bind address; only a loopback address is accepted.
`port`	`9230`	The first port tried; a busy port steps up to the next free one, and `0` asks the operating system to assign one.
`clientOrigins`	empty	Extra browser origins accepted by the ingest endpoint, given exactly; loopback origins are always accepted.
`captureFetch`	on	Record the host's `fetch` calls after the inspector starts.
`maxRequestBodyBytes`	8 MiB	The request-body prefix kept for each request.
`maxResponseBodyBytes`	32 MiB	The response-body prefix kept for each request.
`maxBodyChunkBytes`	48 KiB	Raw bytes carried in one body record.
`maxJournalBytes`	256 MiB	Total body bytes the inspector keeps.
`maxRetainedRequests`	2000	Active and completed requests kept.
`maxSourceFrameBytes`	128 KiB	The largest encoded source frame.
`startupTimeoutMs`	10 s	How long the start waits for the inspector to be ready.
`stopTimeoutMs`	5 s	The window for a graceful shutdown before it is ended.
`clientReconnectBaseMs`	250 ms	The starting client reconnect backoff.
`clientReconnectMaxMs`	5 s	The largest client reconnect backoff.
`clientRuntimeTimeoutMs`	30 s	Deadline for one runtime or sources command sent to a client.
`queryTimeoutMs`	10 s	Deadline for one non-DevTools query.

Keep it safe

The DevTools target grants arbitrary code execution in the host and in any connected client through evaluation; host debugger operations add further control on top.
The inspector binds to loopback only, and the ingest socket additionally requires a random token carried in the WebSocket subprotocol. Non-loopback origins are rejected unless you configure them.
The DevTools socket itself has no token: loopback binding is its only access control. Keep the port on this computer, and stop the run when you are done.
Fetch capture does not redact. Credentials, cookies, query values and payloads can be recorded, so treat captures as sensitive.

Messages you may see

Inspector Client query socket is not connected: a query was sent while the client's socket was between connections. Wait for it to reconnect and try again.
inspector: Client source is closed: the client side was already closed when it tried to update its state, as happens during teardown. Reload the page if the client should still be connected.
[inspector] Client source rejected: <message>: the inspector refused a browser client as a source; the message carries the reason, and the client closes that connection and retries with backoff.
inspector protocol: Worker frame exceeds <n> bytes: an incoming frame was larger than the frame limit; the connection closes and reconnects with backoff.
Client source result exceeds the source-frame byte limit: a sources answer did not fit in one frame and was refused. Read less at once, or raise maxSourceFrameBytes.

Limits worth knowing

A separate worker, no restart. DevTools state lives in its own worker process and never reads the app's live objects, only the snapshots taken for inspection. If it exits unexpectedly, the inspector fails for that run; restart the run to get it back.
Client evaluation can be blocked. A client page's content security policy can refuse dynamic evaluation, and a client context has no DevTools command-line helpers.
Capture has a cost. Full capture copies request and response streams and can add memory and I/O pressure; the retained-byte limit does not cover the buffering inside the stream copy.
Client identity. A client keeps its identity across refreshes and reconnects, while a duplicated live tab gets a new one; a browser without Web Locks support cannot tell two live copies apart.

Questions, answered

Why can I not set breakpoints in a browser client?

Client debugging is not supported. A client offers console entries, evaluation and read-only sources; breakpoint, step and call-frame requests are refused, and pause and resume control the host only.

Which requests does the Network panel miss?

The capture covers the host's fetch calls only. Direct low-level HTTP client calls and fetch references the app kept before the inspector started are not observed, and a client page's own requests are not captured.

What port does the inspector use?

9230 by default. A busy port steps up to the next free one, and 0 asks the operating system to assign one; set port in the overlay to start somewhere else.

Do captures contain credentials?

Yes. Fetch capture records headers, bodies and query values without redaction, so credentials, cookies and payloads can appear. Treat captures as sensitive and keep the inspector on this computer.

Is it safe to leave the inspector running?

Treat it as full access to the app while it runs: anything attached can run code in the host and its clients, the DevTools socket has no token, and loopback binding is its only access control. Stop the run when you are done.

Can I read the tree without a DevTools session?

Yes. The tree read needs no session and no other domain enabled, so it can come from a script or a plugin as well as from the DevTools window.

What happens to a client when it disconnects?

Its console context and live object handles are destroyed at once, and its tree stays as the last snapshot until it reconnects and sends a new one. The inspector keeps up to eight disconnected trees.

Why is a captured body truncated?

The body limits keep a prefix of each request and response and mark the rest truncated. Raise maxRequestBodyBytes or maxResponseBodyBytes in the overlay if you need more.

Does the inspector change what the model sees?

No. It observes runtime activity without changing model requests.