Hey devs 👋
OrinIDE is an AI-powered code editor that runs entirely in your browser — no cloud account, no subscription, nothing uploaded...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks so much, @ben — genuinely didn't expect this. Really appreciate the 🦄 and ❤️, especially coming from you. Means a lot to see the honest-about-what-broke approach land rather than just the highlight-reel version. Motivates me to keep building — and keep being straight about the rough edges — in the next update. 🙏
The local-first part is interesting because it changes the trust model. If the editor can keep code, context, and agent actions local by default, the hard work becomes observability: what changed, which agent did it, and how a developer rolls it back.
You've named the real gap. What exists today: a per-file snapshot stack (last 20 versions, content + timestamp only) backing plain undo — no agent attribution, no run ID, no way to revert a whole agentic pass across files as one unit. Each file's history is anonymous and independent.
So right now local-first trades a cloud audit trail for a worse local one, which defeats the point.
What I'd build: tag each snapshot with the agent role + a shared run ID during Agentic Mode, so history reads "Coder @ 14:02, Reviewer patch @ 14:03" instead of anonymous diffs — plus a "revert this run" action that rolls back every file it touched in one shot.
Filing it next to the Reviewer-loop and cutoff-anchoring issues — same theme: prove what it did, don't just claim it.
That run-level revert is the missing trust feature. Per-file snapshots help when a human made one change; agentic work usually touches a cluster of files for one intent. A shared run ID turns undo from archaeology into an operation.
Exactly — that's the right way to put it, "archaeology into an operation" is the whole difference. Per-file undo assumes you know which files to even go looking in; a five-file agentic run breaks that assumption immediately, and right now the tool has no answer for "just put it back."
The shared run ID is really the whole fix here — once every snapshot written during a pass carries it, "revert this run" is just a filter-and-restore over that ID rather than new machinery. So it's less a new feature than exposing structure that should've been there in the snapshot data from the start.
Going to scope it as: run ID generated once per Agentic Mode invocation, attached to every snapshot write during that run (including the ones the Reviewer/Integrator steps trigger), plus one action that reverts the full set. I'll post here once it's up — this thread's basically turned into the real changelog for the next release.
Yes. The moment the run ID exists, undo becomes a product feature instead of a forensic exercise. I would also want the UI to show the run as a single unit before restore: files touched, generated artifacts, commands run, and any external effects that cannot be rolled back automatically.
Owning the v1.0.8 crash in the post instead of quietly patching it earns a lot of goodwill, and it's a nice touch that the bug was itself a scope problem. I'm curious about the self-healing bit where an agent "picks back up if a response gets cut off mid-file." How does it know where the cutoff landed? Re-sending from the last complete line is easy, but if a response gets truncated in the middle of a function the safe boundary isn't obvious, and that's where I'd expect a resume to quietly corrupt a file. Would love to hear what it anchors on.
Short answer, no anchor exists — it detects that a cutoff happened, not where it's safe to resume from.
It knows a response was truncated via the provider's
finish_reason(length/max_tokens) — that part's reliable. But the "continue" step is just a prompt: "Continue exactly from where you stopped, don't repeat or restart, close any open fence/patch." It's trusting the model's own memory of its last few tokens. Nothing diffs against the last complete line, nothing checks brace/indent balance, nothing verifies the stitched result is actually valid syntax before handing it to the next agent.So you're right — a mid-function cutoff is exactly where this could quietly corrupt a file, and today nothing would catch it.
What I'd add: parse-check the merged output before accepting it (cheap and catches broken stitches immediately), echo back the last few complete lines verbatim in the continue prompt instead of relying on the model's memory, and if the parse check fails, re-run the agent's turn instead of forwarding a bad merge.
Tracking it next to the Reviewer-loop issue — same root cause: the pipeline verifies intent, not outcome.
Thanks for sharing!
Actually really cool, hosting it in browser is basically just cutting out the illusion most IDEs have... They're built on Electron, which hosts it's own chromium, so they're actually browser-IDEs they just wont admit it. Atleast yours is transparent about it and you dont run the bloat of chromium for the IDE + the browser you already have open.
Exactly — that's the part that always got me about the Electron pitch. VS Code, Atom, basically every "native" editor of the last decade is a Node backend + Chromium, just shipped as one bundle so it feels like an app. You're paying the RAM cost of a whole second browser whether you open a real one or not.
OrinIDE just skips the part where it pretends. npx orin-ide spins up a small local Node server (that's what handles the filesystem, terminal sessions, git, model calls) and you point your existing browser at localhost:3000. Same shape everyone else uses under the hood — I just didn't bundle a Chromium to hide it.
Tradeoff is real though, worth being straight about: Electron apps get things like native file dialogs, OS-level shortcuts, tray icons, offline-by-default packaging — stuff you get "for free" when you own the whole window. Running in a normal tab means I have to build around browser sandboxing for some of that (that's part of why the terminal and git are ops through the local server over a websocket instead of direct syscalls from the frontend). So it's not that browser-hosted is strictly better — it's a different set of tradeoffs, just an honest one instead of a hidden one.
Respect for owning the v1.0.8 breakage instead of quietly patching it. The piece I'd want to see next is how the handoff between agents gets validated, since an Architect to Coder to Reviewer chain only helps if the Reviewer can actually reject and loop back, otherwise it is four sequential single-shots. Does the Reviewer stage run anything concrete like tests or a diff check, or is it another model pass judging the output?
Good question, and honestly — no, not yet. Right now it's the second option: four sequential single-shot passes, not a real gate.
The Reviewer does produce a structured review (severity-tagged: CRITICAL / MAJOR / MINOR, each with a suggested patch), and that gets passed forward as context to the Integrator, whose prompt says "address all Reviewer feedback." But that's enforced by instruction, not by code. Nothing actually checks whether the Integrator resolved those issues, nothing runs tests, and there's no loop back to the Coder if the Reviewer flags something critical — it just moves forward regardless.
So you're right to call that out. What I'd want to add: after the Integrator's pass, actually run the project's test/build commands if they exist, and/or do a second narrow Reviewer pass that just checks "were these specific issues resolved, yes or no" — and only pass if they were, otherwise kick it back to the Coder with the unresolved list. That turns it into a real loop with an exit condition instead of a fixed relay.
Appreciate you pushing on this — turning it into a tracked issue instead of a someday-maybe. Will link it here once it's up.
The part that stands out to me is the reviewer stage producing feedback without ever confirming the integrator actually fixed it before shipping. I've watched agent pipelines do exactly that, the review step exists and looks thorough, but nothing checks that the fix landed, so a severity tagged issue can survive all the way to the final commit. Owning the scope bug from v1.0.8 in public is the right call too, a leftover reference to a variable from a different function's scope is exactly the kind of mistake that only shows up once real users are sending agent turns back to back. I would make that reviewer stage block the ship until it can prove resolution, not just flag it and move on.
Exactly right — and it's the sharper version of the same gap. Right now severity tags are advisory: CRITICAL and MINOR both hand off to the Integrator as text and both ship regardless of whether they were fixed. The tag informs a human reading the log; it does nothing to control flow.
"Block until proven" means: Reviewer's findings become a checklist with IDs, a post-Integrator pass checks each ID against the final diff pass/fail, and CRITICAL failures reopen with the Coder — not the whole task from scratch, just that unresolved item. MAJOR/MINOR can still ship but flagged as unresolved; CRITICAL should hard-block.
And it's the same lesson as the v1.0.8 bug from the other direction — a stage that looks like it's doing its job passes every review that doesn't actually execute it. Verify outcomes, not that a step ran. Tracking both the same way now.