In-app copilot
You’re in the application, staring at the bug. The agent is in another window, blind — and the work turns into describing in prose what’s right in front of you. Spaccy’s bridge runs inside your application in development: the copilot starts to see the screen, the error and the element you pointed at, without you ever leaving it.
Development-only, by construction — no symbol of the bridge survives the production build, and that’s verified by a test against the built artifact.
What the agent starts to see
Half of any conversation with an agent is rebuilding, in text, what’s already on the screen. That half disappears.
The bridge publishes the application, the URL, the route and the framework on every navigation — without rebuilding the conversation. You stop writing “I’m on the signup screen, on the address tab, with the form already filled in”: the agent already knows.
Console errors and requests that came back 400 or 500 in the current window arrive together with your question, stack trace intact. The cycle of copying the error from DevTools, pasting it in the chat and hoping you didn’t cut off the line that mattered simply disappears.
Reloading the application — or hot reload firing on its own — reattaches the same session by id, with the messages and pending approvals intact. No orphaned sessions, no context rebuilt from scratch just because you saved a file.
From the pixel to the file
The question that eats the most time in a large codebase isn’t how to fix it — it’s where this is generated. The bridge answers from the screen’s side.
A selection overlay lets you click the element — and the ↑ ↓ arrows move up and down the hierarchy when what you want is the container, not the button. Up to ten elements can go together in the same turn, each identified individually.
When the project has the build plugin, the origin comes with file, line and column. Without it, the search drops down two more layers of clues and returns ranked candidates — each with its own confidence level and the evidence behind it.
The panel says, in plain terms, that these are ranked hypotheses and that the agent confirms by reading the file. No candidate is presented as truth — which avoids the worst failure of this kind of tool: pointing at the wrong file with conviction and sending the agent off to rewrite it.
From the screen to the rest of the harness
Starting from the element you pointed at, the bridge walks the path backward — from the file back to the artifacts that cite it — and brings up the proposal, the specification or the architecture decision that produced that screen. And if no artifact cites the file, it says it found nothing, instead of making up a plausible answer.
Found a bug while browsing around? The report goes out from right there, already carrying route, element, console error and a screenshot — and it enters the pending-items registry as a tracked item, with severity and an owner. The bug stops depending on someone remembering to open the ticket later.
Before sending, the panel shows exactly what’s going to the agent, with passwords, tokens and authorization headers already replaced with [redacted]. If something there shouldn’t go out, you remove the element before sending. The review is yours, and it happens before — not after.
When the agent acts
An agent that clicks and types in your application is useful, and it’s dangerous — in that order. That’s why acting was born locked down: every lock below is code, not a recommendation.
The agent can click an element, fill a field and navigate to a route. Nothing else. The vocabulary is closed at the protocol level and checked by tests on both sides — a command outside the list is refused by design, not by a forgotten case.
click · fill · navigate-route
Every action opens a request in the panel with the action, the target, the value and the route, and it expires on its own if you don’t decide. The “always allow” button doesn’t exist on purpose: the warning on screen is that the action isn’t undone by git, and that’s exactly why it can’t be authorized in bulk.
Allow once · Deny
If the application’s origin isn’t loopback, the command is refused — and that refusal has no override, not by configuration, not by admin permission. The agent doesn’t act on a published application because no code path allows it to.
Cutting the channel is your action, from the application’s side. Once the channel is cut, every command that arrives afterward is refused automatically. And any field that looks like a password, token or secret is refused as a target before the request even appears.
How it gets into your application
One command installs, verifies and uninstalls. Uninstalling returns the file to the exact byte it was before, proven by checksum — not “should be back to normal.”
In a Vite project, the bridge enters as a plugin — and that’s the vector that enables the most precise anchoring, with file, line and column. The install is genuinely verified: the engine loads the resulting configuration and proves the plugin is there.
When you can’t touch the project — another framework, a third-party repository, a policy against changing files — the bridge enters through a proxy in front of the dev server, injecting the loader into HTML responses and passing hot reload through intact. Zero files touched in your repository.
Running it twice doesn’t duplicate anything, and the engine refuses to install when it can’t mechanically prove the result — in that case it points you to the proxy, instead of leaving a half-finished install that only shows up when you go to use it.
# inside your AI agent:
> /bridge install --app web --vector vite
> /bridge status --app webRequest early access and bring the copilot into the application you're already building.