Show HN: OpenBrowserClaw – No Mac Mini. No VPS. No Cloud Deploy. Just Open a Tab
openbrowserclaw.comI was wondering... why do we need a Mac Mini, a VPS, or a Docker container to run OpenClaw?
Your browser already has a secure sandboxed OS, a database, a filesystem, and a JS engine. What if we just... used those?
So I built OpenBrowserClaw inspired by the simplicity of NanoClaw but running entirely in a browser tab.
- Claude API with full tool-use loop
- Shell commands in a v86-emulated Alpine Linux (yes, a Linux VM in WASM, in your browser)
- File I/O via OPFS
- Data persistence in the browser local storage
- Telegram integration over plain HTTPS
- Zero runtime dependencies
No server. No deploy. No infra. Open a tab, paste your Claude API key, start chatting.
It even works as a PWA, install it on your phone if you want.
The whole thing is MIT-licensed and open source: https://github.com/sachaa/openbrowserclaw
Or just try it right now without cloning anything: https://www.openbrowserclaw.com/
Sometimes the best server is the one you already have open. Pretty cool! Some questions about security, because the Github and website make a lot of claims about being fully "secure" by default: 1) What exactly does "encrypted" protect against if there's no passphrase being used? The key sits in IndexedDB right alongside the encrypted data. 2) Why can Claude POST any data it wants to any URL on the internet without any user confirmation? 3)Why is the Telegram bot token stored in plaintext when the Anthropic is protected by AES256? Telegram bot token isn't as sensitive, or what? 4) The javascript tool runs eval() in a Worker that has fetch(), so doesn't that make any fetch_url restriction pointless? The javascript tool can just do the fetch it wants inside of the eval. Thanks for the feedback. This is a proof of concept, not production-hardened software, and the README should be clearer about that. To your questions: - 1. The CryptoKey is extractable: false, so JS can't export the raw key material, it only exposes encrypt/decrypt operations. It won't stop a full XSS attack on the same origin, but it does prevent casual inspection of IndexedDB/DevTools. Defense in depth, not a silver bullet. - 2 & 4. You're right, the fetch_url tool and javascript eval in the worker both have unrestricted network access. A confirmation step for outgoing requests is worth adding. Good callout. - 3 Honest oversight, no reason the Telegram token shouldn't get the same treatment. Will fix. Updating the security language in the README to be more accurate about the threat model. PRs welcome if anyone wants to tackle sandboxing the JS tool (iframe with a null origin is one approach). This is really interesting how does the cron jobs work? Like if you add a PWA on the phone and set cron job tasks, how does it know to execute if the PWA is not open at the time? Thanks! Currently the scheduler runs on the main thread. It checks every 60s and fires due tasks while the app is open. So it works well for recurring prompts during active use, but won't fire if the PWA is closed since browsers don't support persistent background timers. Periodic Background Sync is the closest web API but it's Chrome-only with no timing guarantees, so for now pinning the tab is the reliable path. Quite a long name... People dont say GNU/Linux since it's longer, so they may not really be happy to say OpenBrowserClaw