Flue introduces `$ flue add url` for remote sandbox connectors

• FredKSchott's preview showed a new $ flue add url flow that points at a sandbox provider's docs or SDK and has a coding agent write the connector into your codebase.
• In the follow-up example, the command prints install instructions that can be piped into Claude, OpenCode, Codex, or Cursor Agent instead of pulling a prebuilt package.
• The idea fits Flue's existing framing on its official site and in the GitHub repo: an agent harness with either remote sandboxes or a built-in virtual sandbox, shipped as a headless TypeScript framework.
• Schott's reply about third-party plugins and his later fix make the design motive unusually explicit: avoid another plugin ecosystem, even if that means the docs generator itself needs cleanup.
• the PyFlue repost and the Unkey deployment example suggest the bigger story is not one command, but Flue turning into a testbed for self-authored connectors, ports, and deploy targets.

You can browse the main repo, skim the Cloudflare deployment guide, and inspect a live Unkey example repo. The weirdest detail came from Schott's screenshot, where the output is not a package install at all, but a prompt generator for whatever coding agent you already use. Then Schott said Flue is becoming a testbed for more radical Astro ideas, which makes this look less like one CLI trick and more like an experiment in replacing add commands with agent-authored integration code.

The new command is simple: give Flue a URL, then let your coding agent turn the provider's own docs into a connector.

From the example output, the flow currently looks like this:

• flue add https://e2b.dev/docs
• --print emits instructions instead of mutating the repo directly
• the printed prompt can be piped into claude, opencode, codex, or cursor-agent
• the fallback is copy-pasting the generated prompt into any agent

That is a nice inversion of the usual CLI integration pattern. Instead of publishing and versioning one connector package per provider, Flue is trying to standardize the prompt that makes the connector.

Flue's repo already has an @flue/connectors package, but Schott's reply says he is deliberately avoiding the old third-party plugin playbook. His line, "never again," came in response to a question about API decisions shaped by maintaining plugin ecosystems before.

That makes $ flue add url read less like convenience sugar and more like an architectural choice:

• connector logic starts from the sandbox provider's docs, SDK reference, homepage, or repo, per Schott's preview
• the agent writes project-specific code locally, instead of consuming a universal integration package
• the printed setup text itself is part of the product surface, which Schott later tweaked to add attribution after feedback

The official Flue site already frames sandbox choice this way: connect your favorite remote sandbox, or use the built-in zero-config virtual sandbox.

Official repo copy and Schott's launch thread describe Flue as a headless TypeScript agent harness, closer to Claude Code's operating model than to a thin model SDK.

Two details matter for this feature:

• Flue treats the agent as model plus harness, a definition that Schott later repeated while crediting outside writing that influenced the design.
• The Cloudflare deployment guide says init() with no arguments gives agents a just-bash virtual sandbox by default, with webhook triggers and typed Valibot result schemas.

That split explains why self-authored remote connectors fit the framework. Flue already assumes the harness owns sandboxing and execution context, whether that context comes from a built-in virtual workspace or an external provider.

The follow-on activity was fast enough to make Schott joke that the software moat lasts about 48 hours, per his later post. Within two days, the ecosystem had already produced two concrete extensions:

• PyFlue: a repost from Vtrivedy10 surfaced a Python-native port, and hwchase17's reply called harness engineering a space that needs more exploration.
• Unkey deploy: Schott's repost pointed to an example Flue server on Unkey with three sample agents: translate, summarize, and analyze.

The Unkey repo is small but useful because it turns the framework's abstractions into a file layout engineers can steal:

• .flue/agents/ for one file per endpoint
• .flue/skills/ for reusable tasks
• .flue/roles/ for role definitions
• Docker-based deployment for long-running agent servers

The most revealing follow-up came after the feature preview. Schott said Flue is becoming a testbed for "more radical Astro ideas," and that seeing the pattern validated here makes it easier to bring similar changes to Astro later.

That gives $ flue add url a second life outside agent tooling. If Flue can replace package-install style setup with agent-generated integration code, it becomes an experiment in how developer frameworks might ship adapters more broadly, starting with agents and possibly ending up back in mainstream framework tooling.