Show HN: OpenBrowserClaw – No Mac Mini. No VPS. No Cloud Deploy. Just Open a Tab (openbrowserclaw.com)
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.
4 comments
[ 2.9 ms ] story [ 16.1 ms ] threadhow 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?
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.
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).