Correction, October 11, 2026: Local development data can contain sensitive information and can be read by a coding agent. Local storage does not guarantee privacy.

What happened

Cloudflare updated its local development tools so a coding agent can inspect your app’s server-side failures directly, without you copying error messages into the chat first.

As of August 4, 2026, wrangler dev (Cloudflare’s command-line tool for running a Worker, code Cloudflare runs without you managing a server, on your own machine before deploying it) and vite dev with Cloudflare’s Vite plugin automatically record what your app did while it ran locally: every outgoing network request and how long it took, every read or write to Cloudflare’s storage and database services, and the full path a request took from start to finish. This record is called an OpenTelemetry trace, an industry-standard way of logging what a program actually did step by step, so a person or an AI agent can inspect recorded operations instead of relying on a single error message.

None of this needs setup. You don’t install a tracing tool, flip a setting, or tell your coding agent to check logs. If Cloudflare’s dev server notices it’s being run inside a supported coding agent’s session, it automatically prints a short hint pointing that agent at a new local API, so the agent can pull the trace data itself.

How the agent uses it

That local API is called the Local Explorer. It’s a REST API, a set of local web addresses a program can call to fetch data, that only runs on your own machine while wrangler dev or vite dev is active. The API publishes a machine-readable list of what it can do, so an agent can work out on its own which operations the API exposes, instead of you spelling it out in your prompt. Through the same API, an agent can also inspect the current state of your local KV store (Cloudflare’s key-value data store), R2 (its file storage), D1 (its SQL database), and Durable Objects (small units of persistent state tied to one instance of your code).

Cloudflare’s own example shows the point: an endpoint that creates orders starts returning server errors after a database schema change. Instead of a person pasting the error into a chat, the agent queries the Local Explorer directly, sees that a database write failed because a column is missing, checks the database schema, finds a migration (a saved set of database changes) that was never applied, applies it, and retests. All of it happens on one machine, with nothing deployed.

What you need to do to get it

Update your tooling: run npm install --save-dev wrangler@latest, or npm install --save-dev @cloudflare/vite-plugin@latest if you build with Vite. Then ask your agent to reproduce and debug the failure locally.

Who should care

This matters if you build on Cloudflare Workers, especially if a coding agent is the one running your dev server and chasing down bugs for you. It doesn’t apply if you deploy elsewhere, like Vercel, Netlify, or Supabase.

Local Explorer exposes local development state rather than the production dashboard. Use synthetic data because local databases and logs can contain sensitive information that a coding agent reads. Local storage does not guarantee that the agent or its provider cannot receive that information.

What builders should do next

Update wrangler or the Vite plugin. In a disposable local project with synthetic data, rename a database column your code still references. Ask the agent to find and fix the resulting failure without telling it what you changed.

Check whether the agent identifies the failing operation, such as the D1 insert on the orders table, from the trace. Review the proposed fix and confirm the same request succeeds afterward.

Local traces make debugging evidence available where the agent is already working. Builders still review the diagnosis and fix, but they need to copy fewer error messages into the conversation.

End of article