Jibe | Devpost

Home origin tracks local installs
About
DOOM
Editor preview
Jibe Shell
MCP Inspector

Inspiration

The first thing I thought when I saw the WebMCP spec was: that would be perfect for integrating dev tools into a frontend framework I'm building.

Then I started thinking about putting the agentic coding environment itself in the browser. That unlocks a few extremely compelling qualities:

The browser is an excellent sandbox.
URLs are the easiest sharing mechanism on earth.
The browser runtime eliminates an entire class of environment mismatches and runtime failures—things like process.env, missing binaries, incompatible runtimes, and "works on my machine" problems.

The bigger idea behind Jibe is that an application doesn't have to be just its built dist/. A mutable source tree, a runtime, and the capabilities needed to operate on them can travel together as one disposable software environment.

WebMCP was the missing piece: Jibe can use WebMCP to build software that itself exposes WebMCP tools. In production, an agent can use the tools built into the application. Flip into development, and that agent can instead get the capabilities it needs to change the application itself.

What it does

Jibe wraps a web application with a small but pluggable framework that adds the concept of an environment to the browser.

It allows for all kinds of interesting designs, but here's what happens in jibe.run when you switch a jibe from PROD to DEV:

The service worker switches from serving built dist/ files to rendering the application's src/.
The root layout changes, moving the application from the root surface into a live preview panel inside an IDE environment.
Development capabilities become available: a file explorer, editor, hot reload, shell, git, and MCP tools that allow an agent to inspect and modify the application live.

The important part is that these are modes of the same environment. Switching between PROD and DEV should feel more like switching a theme than provisioning a new machine.

Jibe is "batteries included" and built for people developing local-first applications with agents. You can build an agentic application that exposes WebMCP tools, then flip into development mode and your agent goes from using the tools you just built to building the feature that adds them.

Jibe runs local-first using browser storage and can connect with WebMCP-compatible agents or local coding agents using the excellent @mcp-b/webmcp-local-relay package.

A jibe hits the jibe.run server on first load to clone and bootstrap a project. After that, it can remain fully functional offline for as long as you want. Navigating to my-custom-app.jibe.run creates a local-first web application and its development environment in seconds.

Point your agents at the URL and have fun.

How we built it

Jibe is structured as a core open-source project and a deployed Solid 2.0 application that consumes it.

The core framework uses a plugin and capability model to support many different use cases. Most users will want to consume core plugins for things like:

Git
Transpiling and building source
Local MCP
Frontend frameworks
Filesystems and storage

An application manifest declares which capabilities are available to an environment, following a principle of least privilege. For example, agents can be given a virtual filesystem containing only files that are safe for them to edit rather than direct access to everything.

One of my favorite agentic features is the Jibe Shell. Agents get a bash tool that parses shell expressions for viewing and editing files as an ergonomic alternative to a collection of bespoke tools like read_file and edit_file.

This also doubles as a terminal surface inside the IDE for users. The shell supports commands that require additional capabilities—effectively sudo commands—which are gated rather than ambient.

The result is something I'm pretty excited about:

Bash ergonomics without ambient authority.

I built this project on my own using Muse Spark 1.X and GLM 5.3 Flash with my trusty OMP and OpenCode harnesses. Lots of back and forth in web chat with Claude and ChatGPT as well.

Coding with agents is the best thing ever.*

When I needed to pick a bundler, I did a little research and then handed the problem to a subagent to stress-test and benchmark half a dozen different options.

The approach I took with this project was to treat the entire project like a harness and make clear distinctions between intent and scratch. An early win was sketching the shape of the system in a messy repository, then treating that prototype as a library for seeding a new repository.

Challenges we ran into

Iteration.

Agent speed is exhausting because, to keep the speed up, you have to keep entropy down.

A particularly bad failure mode is agents placing shims and legacy compatibility code all over the place. Agents will hardcode a "fallback" until the fallback becomes the primary mechanism. Agent-written TypeScript is often effectively just verbose JavaScript.

These are all antipatterns done in the name of preserving a green test suite, so it's a real challenge to see through the act.

Identifying and preventing these failure modes is the primary implementation job. You have to distinguish between code that represents the intended architecture and code that exists because an agent needed to make the next step work.

The faster the agents go, the more aggressively you need to manage that distinction.

Accomplishments that we're proud of

The Jibe Shell and workflows pattern are awesome. I'll be pushing both of these ideas much further.

Bash ergonomics minus ambient authority is incredible. Agents already understand the shell as a general-purpose interface for operating on software. Giving them that ergonomics while constraining the capabilities underneath it feels like a very useful primitive.

I'm also happy that the core interaction works as a proof of concept:

Jibe uses WebMCP to build software with WebMCP.

An application can expose useful tools to an agent in production. Flip into development mode and the agent gets a different environment with the capabilities required to change the source and build new tools. Flip back to production and those tools become part of the application.

What we learned

I learned how far the browser has come as a capable operating system.

The tradeoffs compared with local development using a non-browser JavaScript runtime are worth seriously considering. The biggest feature in favor of the browser is that it sandboxes the agent extremely well.

The big unlock with coding agents locally was allowing them to interface with software in the same way users do. WebMCP promises a similar unlock, with a very important distinction.

Operating system evolution has generally assumed the terminal is safe. Browsers, meanwhile, have spent decades evolving under the assumption that users cannot be trusted.

That distinction matters when the user is an agent.

A browser-native development environment gives us a mature security model for software agents while still exposing the capabilities they need to operate on real software.

What's next for Jibe

I think Jibe has incredible promise for a wide variety of uses.

It is effectively an executable git worktree that provisions from a URL and has better isolation.

Fan out jibes for evals or bakeoffs, then visually inspect the results. Make vibe coding social and collaborative. Give Molty $20 and a jibe and see what happens.

The roadmap includes: