Cloudflare Enables Local OpenTelemetry Tracing for AI Coding Agents in Workers

Cloudflare Enables Local OpenTelemetry Tracing for AI Coding Agents in Workers Cloudflare has updated wrangler dev and vite dev to automatically capture OpenTelemetry traces during local Worker development. When local development tooling detects an AI coding agent session, it directs the agent to the Local Explorer API to inspect telemetry and debug issues without requiring SDKs, manual setup, or prompt modifications. Wrangler dev and vite dev automatically capture OpenTelemetry traces and expose them to coding agents via the Local Explorer REST API. The Local Explorer API features an OpenAPI schema and provides access to correlated console logs alongside state inspection for D1, KV, R2, Durable Objects, and Workflows. Tracing is instrumented directly within workerd, with Miniflare assembling runtime telemetry and persisting it to an internal SQLite-backed Durable Object on localhost. Automated Agent Debugging When an agent runs wrangler dev or vite dev, the server detects the agent session and prints a discovery hint. Through the Local Explorer API's read-only observability endpoint, agents can review execution traces and correlated logs instead of repeatedly adding temporary console logs to identify failing steps. This allows agents to isolate failed operations—such as missing database migrations—in a single local feedback loop before code deployment. Local Explorer Interface and API Local Explorer serves as both a REST API for automated agents and a browser-based UI for human developers, hosted directly on the Worker's localhost origin. Accessible via the local server or by pressing 'e' in Wrangler, developers can inspect request spans, timings, attributes, and errors, as well as browse and edit local binding data across Cloudflare primitives. Runtime Architecture The feature builds on core instrumentation inside Cloudflare's open-source runtime, workerd, which automatically generates spans across handlers such as fetch and scheduled events, in addition to user-defined custom spans. Miniflare gathers these runtime events and console logs, formats them into OpenTelemetry-compliant records, and stores them in an internal SQLite-backed Durable Object that powers the Local Explorer endpoints.

Cloudflare Workers支持本地追踪，助力AI编码代理排查错误 Cloudflare宣布在wrangler dev和vite dev中自动捕获本地Worker调用的OpenTelemetry追踪信息。开发服务器识别到AI编码代理后，会引导其通过Local Explorer API查询追踪和关联日志，无需配置SDK即可在部署前闭环排查并修复本地错误。 wrangler dev与vite dev现已原生支持捕获本地调用追踪，无需安装SDK或修改代码 Local Explorer提供REST API与OpenAPI规范，支持AI代理自主发现端点、查询链路追踪并检查本地存储绑定 底层基于workerd内置探针与Miniflare，将运行时事件与日志聚合存入基于SQLite的内部Durable Object 人类开发者可在本地浏览器访问/cdn-cgi/explorer可视化查看请求Span、耗时、属性及日志 AI代理本地排错闭环 当开发服务器检测到受支持的AI编码代理时，会自动提示Local Explorer的访问路径。由于API根目录提供OpenAPI规范，代理可在运行时自主发现接口。面对报错，代理无需插入临时日志，可直接读取只读可观测性端点，快速定位具体失败操作（如D1缺少数据库迁移），修改环境并二次验证，大幅缩短排查耗时和Token消耗。 Local Explorer与人类可视化界面 除了为AI提供REST接口，Local Explorer还为人类开发者内置了基于浏览器的可视化界面。它直接运行在本地Worker同源地址，开发者按下快捷键e或访问/cdn-cgi/explorer即可打开。用户可在此检查D1、KV、R2、Durable Objects与Workflows的状态，并直接分析请求的Span、耗时、属性和关联的控制台日志。 workerd与Miniflare实现原理 该功能基于workerd运行时内置的探针实现，覆盖fetch、定时任务以及队列处理器等调用场景。本地开发中，Miniflare收集运行时事件和控制台输出，将其组装为OpenTelemetry追踪，并写入由SQLite支撑的内部Durable Object作为本地追踪存储，再通过Local Explorer API向外提供查询服务。

Starting today, `wrangler dev` and `vite dev` automatically capture [OpenTelemetry traces](https://developers.cloudflare.com/workers/observability/traces/) for local Worker invocations. When Cloudflare's tooling detects an agent session, it points the agent to the [Local Explorer API](https://developers.cloudflare.com/workers/local-development/local-explorer/#use-with-ai-coding-agents), a local debugging API where it can query those traces. You do not need to install an SDK, enable tracing, configure your agent, or even mention observability in the prompt. A prompt can be as simple as: This builds on years of investment in local development, from introducing [Miniflare](https://blog.cloudflare.com/miniflare/) to making local mode the default in [Wrangler 3](https://blog.cloudflare.com/wrangler3/). Local traces give coding agents structured feedback from that development environment before code is deployed. As part of its normal workflow, an agent starts `wrangler dev` or `vite dev` to run and test the Worker. When the development server recognizes a supported coding-agent session, it automatically prints a hint that looks like this: The [Local Explorer](http://developers.cloudflare.com/workers/local-development/local-explorer) is a browser-based interface and REST API for viewing and editing local resource data and querying observability data during development. The API root serves an OpenAPI schema, so agents can discover available endpoints at runtime without hardcoded instructions. The automatically captured traces are available through a read-only observability endpoint in that API, together with their correlated console logs. The agent can query this telemetry, then use the API's other operations to inspect local Workers and bindings or examine state in D1, KV, R2, Durable Objects, and Workflows. Consider `POST` `/api/orders`, which retrieves an active cart from KV, saves the checkout details into D1, and sends a message to a Queue for order processing. After a schema change, the endpoint suddenly starts returning a 500 status. The 500 does not identify which operation failed. The agent adds logs around KV, D1, and the Queue, reruns the request, inspects the output, and repeats. Each cycle takes time and burns tokens while the agent reconstructs the request from text. The agent reproduces the error and queries the read-only observability endpoint. The trace shows that the KV read succeeded, the D1 insert failed with `no such column: delivery_window`, and the Queue was never called. Your agent uses the Local Explorer API to access the same trace data you would see here: The agent uses the API to inspect the D1 schema. It finds that the migration adding delivery\_window exists in the repository but has not been applied locally, applies it, sends the request again, and queries the new trace. Issue resolved. In one local loop, the agent identifies the failed operation, fixes the local environment, and verifies the result without deploying or adding temporary logs. Agents query local telemetry through the API, but you as a human can visualize the same data in the [Local Explorer](https://developers.cloudflare.com/workers/local-development/local-explorer/), the browser-based interface built into the local development server. Alongside browsing local binding state, you can select a request to inspect its spans, timing, attributes, errors, and correlated console logs. Local Explorer runs on the same localhost origin as your Worker, not in the Cloudflare dashboard. Press `e` in Wrangler or visit `/cdn-cgi/explorer` on the local server to open it. When we launched [Workers Tracing](https://blog.cloudflare.com/workers-tracing-now-in-open-beta/), we built instrumentation directly into [workerd](https://github.com/cloudflare/workerd), the open-source runtime that powers Workers. Without requiring an SDK or any code changes, the runtime captures spans for: `fetch` to `scheduled` to queue handlers. Any [custom spans](https://developers.cloudflare.com/workers/observability/traces/custom-spans/) emitted by your application will also appear alongside these automatic spans. [Wrangler](https://developers.cloudflare.com/workers/local-development/#start-a-local-development-server) and the [Cloudflare Vite plugin](https://developers.cloudflare.com/workers/vite-plugin/) use Miniflare to run your Worker locally in the same runtime, making this instrumentation available during local development. Miniflare collects runtime events and console output, assembles them into OpenTelemetry traces and correlated logs, then writes the telemetry to an internal SQLite-backed Durable Object that serves as the local trace store. The Local Explorer API exposes that data through the local development server where agents can easily query traces and logs and inspect local state. Update Wrangler or the Cloudflare Vite plugin, whichever your project uses: Then ask your agent to debug locally as you normally would. Your agent can already write and run your Worker locally — now it can see what happened, fix what failed, and verify the result before you deploy. Check out the [docs](http://developers.cloudflare.com/workers/local-development/local-explorer/#api) to learn more!