Public conversation snapshot
Follow the community thread graph.
Vibecodr conversations collect launch notes, feedback, architecture questions, and discussion around runnable web apps. This fallback keeps the public thread index linkable even when the SPA shell is not executing.
- Hottest
- Section: technical-updates
-
@vibecodr • Mar 18, 2026 • Technical updates
Runtime Bump 1.31
Runtime now can request MIDI access from users
-
@vibecodr • Mar 13, 2026 • Technical updates
NEW FEAT: BUMP IT
I've been working on a better way to update apps on Vibecodr without accidentally turning one project into a pile of duplicate listings. BUMP IT is now the canonical way to publish a new version of an existing app. Instead of making a brand new top-level post every time you improve something, BUMP IT keeps the same app identity, ships the latest version live, and preserves your version history underneath it. The goal is simple: one app can grow over time, your old cuts still exist, and updating an app feels like continuing the same project instead of starting over every time. If you’re the owner of an app, you’ll now see BUMP IT in the right places. Open it, jump straight into Studio update mode, and ship the next version.
-
@vibecodr • Mar 12, 2026 • Technical updates
runtime bump v 0.1.28
v0.1.28 is a stability-focused runtime upgrade for HTML vibes. We tightened the contract between compilation and playback so published HTML runs from a normalized bundle with explicit runtime metadata instead of depending on brittle browser-time behavior. The runtime now handles import maps and module preloads more deliberately, resolves relative assets against the actual artifact bundle, and surfaces execution-plan drift as structured runtime failures instead of opaque breakage. The result is a runtime that is stricter than older versions, but much more predictable across Studio previews, published vibes, and VXBE runtime hosts.
-
@vibecodr • Mar 24, 2026 • Technical updates
Runtime Bump! V 0.2.4
We’ve been doing a pretty deep pass on the runtime lately, mostly focused on making it feel less fragile and more honest about what’s actually happening under the hood. The biggest change is that runtime launch is now driven by a cleaner manifest-backed contract instead of a bunch of scattered client-side assumptions. That means public and auth-pending launches behave much better while auth is still resolving, runtime sessions stay alive through permission changes, and focused/player surfaces come up more reliably without weird focus or warmup glitches. We also tightened up manifest + mirror handling so public runtime assets converge faster and stay more consistent once they’re live. On the product side, we aligned the “link-visible” behavior across the player, feed, and focused overlay, which gets rid of a bunch of edge-case weirdness around what should be viewable, remixable, or just hidden from homepage discovery. We also cleaned up same-origin /api/* runtime routing so backend access follows the same visibility rules as the rest of the public runtime surface. A lot of this work is invisible when it’s working, but that’s kind of the point: fewer brittle launches, fewer confusing state mismatches, and a runtime that feels steadier when people actually use it.
-
@vibecodr • Feb 14, 2026 • Technical updates
runtime update v 0.1.21 minor update
Downloads got smarter. The runtime now mediates downloads through an action-based approval flow instead of blanket permissions, and handles approved blob/data downloads locally inside the iframe. Also squashed a race condition where a download would get approved but never actually fire — turns out the iframe policy needed a beat to propagate before the click would go through
-
@vibecodr • Feb 14, 2026 • Technical updates
runtime update v0.1.19
This round was mostly about tightening isolation and making capability handling more consistent in edge cases. I hardened URL resolution inside sandboxed iframes so things don’t break when window.location ends up as about:srcdoc. Popup requests, link navigation, and download flows now go through a consistent absolute URL resolver. It sounds small, but it closes a class of subtle sandbox issues. Download handling is also cleaner. Programmatic downloads (like <a download.click() flows) are now intercepted properly, and blob/data URLs go through a safer conversion path. Whether a file is static or dynamically generated, the capability prompt behaves the same way. I also bumped the runtime to v0.1.19 and rolled the new bundle set, refreshed cache busting, and aligned the runtime index so the hardening changes are actually what’s running in production. On the HTML runtime side, external scripts now execute through a safer fetch+blob flow with improved module specifier handling. This makes CSP behavior inside sandboxed frames more predictable and less fragile. Test coverage around script replay was expanded as part of that. No breaking changes. Just structural tightening so the runtime behaves consistently under isolation and doesn’t rely on lucky assumptions. Less visible work, more integrity under the hood.
-
@vibecodr • Mar 11, 2026 • Technical updates
Runtime bump v1.23
We just bumped the runtime to v0.1.23 and tightened a few things that make the live player feel a lot more reliable. The biggest change is that sharing is now single-flight across the app, so repeated taps on Share no longer trip the browser’s “earlier share has not yet completed” error or spam false failure telemetry. On the HTML runtime side, we also cleaned up how third-party scripts are handled: old Ahrefs and Cloudflare beacon snippets get stripped out, raw cdn.tailwindcss.com scripts are removed, and HTML vibes now consistently rely on Vibecodr’s self-hosted Tailwind runtime instead of a cross-origin CDN fetch that the sandbox can’t load anyway. We also added a serve-time safety pass for legacy HTML bundles, which means older published vibes can benefit from those fixes without needing a manual republish. And because the Tailwind runtime is self-hosted here, we removed the misleading upstream CDN warning from the shipped runtime asset so the console reflects what the platform is actually doing now: fewer false errors, cleaner runtime behavior, and much more predictable HTML vibe execution.
-
@vibecodr • Feb 8, 2026 • Technical updates
Enhance Private vibe access reliability and HTML upload reliabiltiy
- Fixed an issue on our side where some “small, simple HTML” vibes could fail to publish and show up as TypeError: Failed to fetch. This happened because we sometimes mis-detected HTML fragments (for example < div > Hello< / div > ) as React/TSX and routed them through the JSX compilation path, and because our server-side HTML sanitization could hit Worker runtime limits and get hard-killed (meaning no JSON error response and no server telemetry). We fixed this by treating HTML fragments as HTML and normalizing them into a minimal full HTML document, plus adding quota preflight + size caps around sanitization and re-validating quotas using the sanitized bundle size. - Fixed private vibe owner access reliability: owners should always be able to run their own private vibes. We found cases where private bundle fetches could 404 because the runtime didn’t consistently know it needed a bundle grant first and parts of the flow depended on an internal proxy. We fixed this by serving bundle grants directly from the API worker, exposing bundleGrantRequired in runtime manifests so the runtime always requests a grant before fetching a private bundle, and tightening bundle URL handling and token redaction in logs/telemetry.