Feature request: First-class external development and automated debugging workflow for Gadgets

[luxingxiao]

Summary

Cloudflare OS provides an integrated environment for building Gadgets, but there does not appear to be a documented, first-class workflow for developing and debugging a Gadget with external coding agents and development tools such as Codex, Claude Code, Playwright, Chrome DevTools, or a DevTools MCP server.

For conventional web applications, an external agent can usually:

1. Edit files in a local Git repository.
2. Start the development server.
3. Open the application in a browser.
4. Inspect the DOM, console, network activity, and runtime errors.
5. Interact with the application through browser automation.
6. Modify the code and repeat until the behavior is verified.

It would be valuable to support an equivalent feedback loop for Gadgets while still running them inside the real Cloudflare OS sandbox and capability model.

Current limitation

Gadget source and runtime state are managed by the Workshop rather than represented as a normal local source directory. Blueprint export is useful for distribution, but the .gadget format is a binary Yjs snapshot rather than a source-oriented development format.

As a result, I have not found a supported way for an external development agent to:

• Check out a Gadget as ordinary files.
• Push file changes back into an existing Gadget.
• Watch a local directory and synchronize changes automatically.
• Start or reload a specific Gadget through a CLI or development API.
• Run an end-to-end test against a known Gadget and receive machine-readable results.
• Subscribe to client exceptions, console messages, RPC failures, Dynamic Worker errors, and other runtime diagnostics in one place.
• Reliably use Playwright, CDP, or DevTools-based tools as part of an automated edit-run-observe-fix loop.

The built-in coding agent can edit Gadget files, and developers can inspect code and add logging, but external agents cannot easily participate in the same runtime feedback loop. This makes complex debugging substantially slower than development of a conventional local web application.

Desired outcome

The goal is not necessarily to run Gadgets outside Cloudflare OS.

A good solution would let external tools edit and test a Gadget while the Gadget continues to run inside the actual local Cloudflare OS environment, including:

• The sandboxed client iframe.
• Dynamic Workers or Facets.
• Durable Object state.
• Cap'n Web RPC.
• Gadget bindings and Gatekeepers.
• The existing capability and approval model.

Possible development experience

For example, Cloudflare OS could provide a development-only CLI:

# Export a Gadget into a source-oriented local directory.
pnpm gadget pull <gadget-id> ./gadgets/my-gadget

# Apply local source changes to the Gadget.
pnpm gadget push <gadget-id> ./gadgets/my-gadget

# Continuously synchronize changes.
pnpm gadget watch <gadget-id> ./gadgets/my-gadget

# Run an automated test and emit structured diagnostics.
pnpm gadget test <gadget-id> --reporter=json