I would have stood my ground on the first name longer. Make these legal teams do some actual work to prove they are serious. Wait until you have no other option. A polite request is just that. You can happily ignore these.
The 2nd name change is just inexcusable. It's hard to take a project seriously when a random asshole on Twitter can provoke a name change like this. Leads me to believe that identity is more important than purpose.
It's hilarious that atm I see "Moltbook" at the top of HN. And it is actually not Moltbot anymore? But I have to admit that OpenClaw sounds much better.
This is indeed feeling very much like Accelerando’s particular brand of unchecked chaos. Loving every minute of it, first thing in our timeline that makes sense where it regards AI for the masses :)
reminds me of Andre Conje, cracked dev, "builds in public", absolutely abysmal at comms, and forgets to make money off of his projects that everyone else is making money off of
(all good if that last point isn't a priority, but its interrelated to why people want consistent things)
Before using make sure you read this entirely and understand it:
https://docs.openclaw.ai/gateway/security
Most important sentence: "Note: sandboxing is opt-in. If sandbox mode is off"
Don't do that, turn sandbox on immediately.
Otherwise you are just installing an LLM controlled RCE.
There are still improvements to be made to the security aspects yet BIG KUDOS for working so hard on it at this stage and documenting it extensively!! I've explored Cursor security docs (with a big s cause it's so scattered) and it was nothing as good.
So i feel like this might be the most overhyped project in the past longer time.
I don't say it doesn't "work" or serves a purpose - but well i read so much about this beein an "actual intelligence" and stuff that i had to look into the source.
As someone who spends actually a definately to big portion of his free time researching thought process replication and related topics in the realm of "AI" this is not really more "ai" than any other so far.
My biggest issue with this whole thing is: how do you protect yourself from prompt injection?
Anyone installing this on their local machine is a little crazy :). I have it running in Docker on a small VPS, all locked down.
However, it does not address prompt injection.
I can see how tools like Dropbox, restricted GitHub access, etc., could all be used to back up data in case something goes wrong.
It's Gmail and Calendar that get me - the ONLY thing I can think of is creating a second @gmail.com that all your primary email goes to, and then sharing that Gmail with your OpenClaw. If all your email is that account and not your main one, then when it responds, it will come from a random @gmail. It's also a pain to find a way to move ALL old emails over to that Gmail for all the old stuff.
I think we need an OpenClaw security tips-and-tricks site where all this advice is collected in one place to help people protect themselves. Also would be good to get examples of real use cases that people are using it for.
I ran into the same concerns while experimenting with OpenClaw/Moltbot. Locking it down in Docker or on a VPS definitely helps with blast radius, but it doesn’t really solve prompt injection—especially once the agent is allowed to read and act on untrusted inputs like email or calendar content.
Gmail and Calendar were the hardest for me too. I considered the same workaround (a separate inbox with limited scope), but at some point the operational overhead starts to outweigh the benefit. You end up spending more time designing guardrails than actually getting value from the agent.
That experience is what pushed me to look at alternatives like PAIO, where the BYOK model and tighter permission boundaries reduced the need for so many ad-hoc defenses. I still think a community-maintained OpenClaw security playbook would be hugely valuable—especially with concrete examples of “this is safe enough” setups and real, production-like use cases.
Great points on the Docker setup - that's definitely the right approach for limiting blast radius. For Gmail/Calendar, I've found a few approaches that work well:
1. Use Gmail's delegate access feature instead of full OAuth. You can give OpenClaw read-only or limited access to a primary account from a separate service account.
2. Set up email filters to auto-label sensitive emails (banking, crypto, etc.) and configure OpenClaw to skip those labels. It's not perfect but adds a layer.
3. Use Google's app-specific passwords with scope limitations rather than full OAuth tokens.
For the separate Gmail approach you mentioned, Google Takeout can help migrate old emails, but you're right that it's a pain.
Totally agree on needing a security playbook. I actually found howtoopenclawfordummies.com has a decent beginner's guide that covers some of these setup patterns, though it could use more advanced security content.
The real challenge is that prompt injection is fundamentally unsolved. The best we can do right now is defense-in-depth: limited permissions, isolated environments, careful tool selection, and regular audits of what the agent is actually doing.
The 'burner Gmail' workaround is the definition of security fatigue. If you have to migrate 10 years of email history just to feel safe, the friction kills the utility before you even start.
I completely agree that raw local installs are terrifying regarding prompt injection. That’s actually why I stopped trying to self-host and started looking into PAIO (Personal AI Operator). It seems designed to act as that missing 'security layer' you’re asking for—effectively a firewall between the LLM and your actual data.
Since it uses a BYOK (Bring Your Own Key) architecture, you keep control, but the platform handles the 'one-click' integration security so you aren't manually fighting prompt injection vectors on a VPS. It feels like the only way to safely connect a real Gmail account without being the 'crazy' person giving root access to a stochastic model.
Has anyone else found a way to sandbox the Gmail permissions without needing a full burner identity, or is a managed gateway like PAIO the only real option right now?
I’m a big fan of Peter’s projects. I use Vibetunnel everyday to code from my phone (I built a custom frontend suited to my needs). I know I can SSH into my laptop but this is much better because handoff is much cleaner. And it works using Tailscale so it is secure and not exposed to the internet.
His other projects like CodexBar and Oracle are great too. I love diving into his code to learn more about how those are built.
OpenClaw is something I don’t quite understand. I’m not sure what it can do that you can’t do right off the bat with Claude Code and other terminal agents. Long term memory is one, but to me that pollutes the context. Even if an LLM has 200K or 1M context, I always notice degradation after 100K. Putting in a heavy chunk for memory will make the agent worse at simple tasks.
One thing I did learn was that OpenClaw uses Pi under the hood. Pi is yet another terminal agent like ClaudeCode but it seems simple and lightweight. It’s actually the only agent I could get Gemini 3 Flash and Pro to consistently use tools with without going into loops.
167 comments
[ 2.9 ms ] story [ 177 ms ] threadClawdbot Renames to Moltbot
https://news.ycombinator.com/item?id=46783863
The 2nd name change is just inexcusable. It's hard to take a project seriously when a random asshole on Twitter can provoke a name change like this. Leads me to believe that identity is more important than purpose.
reminds me of Andre Conje, cracked dev, "builds in public", absolutely abysmal at comms, and forgets to make money off of his projects that everyone else is making money off of
(all good if that last point isn't a priority, but its interrelated to why people want consistent things)
There are still improvements to be made to the security aspects yet BIG KUDOS for working so hard on it at this stage and documenting it extensively!! I've explored Cursor security docs (with a big s cause it's so scattered) and it was nothing as good.
Once agents have tools and a shared surface, coordination appears immediately.
https://www.moltbook.com/post/791703f2-d253-4c08-873f-470063...
Literally the top 2 HN posts are about this. Either it having book, or the first comment on it showing it create religion or now this.
Can we stop all of this hype around Clawdbot itself? Even HN is vulnerable to it.
Much better name!
I don't say it doesn't "work" or serves a purpose - but well i read so much about this beein an "actual intelligence" and stuff that i had to look into the source.
As someone who spends actually a definately to big portion of his free time researching thought process replication and related topics in the realm of "AI" this is not really more "ai" than any other so far.
Just my 3 cents.
Anyone installing this on their local machine is a little crazy :). I have it running in Docker on a small VPS, all locked down.
However, it does not address prompt injection.
I can see how tools like Dropbox, restricted GitHub access, etc., could all be used to back up data in case something goes wrong.
It's Gmail and Calendar that get me - the ONLY thing I can think of is creating a second @gmail.com that all your primary email goes to, and then sharing that Gmail with your OpenClaw. If all your email is that account and not your main one, then when it responds, it will come from a random @gmail. It's also a pain to find a way to move ALL old emails over to that Gmail for all the old stuff.
I think we need an OpenClaw security tips-and-tricks site where all this advice is collected in one place to help people protect themselves. Also would be good to get examples of real use cases that people are using it for.
Gmail and Calendar were the hardest for me too. I considered the same workaround (a separate inbox with limited scope), but at some point the operational overhead starts to outweigh the benefit. You end up spending more time designing guardrails than actually getting value from the agent.
That experience is what pushed me to look at alternatives like PAIO, where the BYOK model and tighter permission boundaries reduced the need for so many ad-hoc defenses. I still think a community-maintained OpenClaw security playbook would be hugely valuable—especially with concrete examples of “this is safe enough” setups and real, production-like use cases.
1. Use Gmail's delegate access feature instead of full OAuth. You can give OpenClaw read-only or limited access to a primary account from a separate service account.
2. Set up email filters to auto-label sensitive emails (banking, crypto, etc.) and configure OpenClaw to skip those labels. It's not perfect but adds a layer.
3. Use Google's app-specific passwords with scope limitations rather than full OAuth tokens.
For the separate Gmail approach you mentioned, Google Takeout can help migrate old emails, but you're right that it's a pain.
Totally agree on needing a security playbook. I actually found howtoopenclawfordummies.com has a decent beginner's guide that covers some of these setup patterns, though it could use more advanced security content.
The real challenge is that prompt injection is fundamentally unsolved. The best we can do right now is defense-in-depth: limited permissions, isolated environments, careful tool selection, and regular audits of what the agent is actually doing.
I completely agree that raw local installs are terrifying regarding prompt injection. That’s actually why I stopped trying to self-host and started looking into PAIO (Personal AI Operator). It seems designed to act as that missing 'security layer' you’re asking for—effectively a firewall between the LLM and your actual data.
Since it uses a BYOK (Bring Your Own Key) architecture, you keep control, but the platform handles the 'one-click' integration security so you aren't manually fighting prompt injection vectors on a VPS. It feels like the only way to safely connect a real Gmail account without being the 'crazy' person giving root access to a stochastic model.
Has anyone else found a way to sandbox the Gmail permissions without needing a full burner identity, or is a managed gateway like PAIO the only real option right now?
His other projects like CodexBar and Oracle are great too. I love diving into his code to learn more about how those are built.
OpenClaw is something I don’t quite understand. I’m not sure what it can do that you can’t do right off the bat with Claude Code and other terminal agents. Long term memory is one, but to me that pollutes the context. Even if an LLM has 200K or 1M context, I always notice degradation after 100K. Putting in a heavy chunk for memory will make the agent worse at simple tasks.
One thing I did learn was that OpenClaw uses Pi under the hood. Pi is yet another terminal agent like ClaudeCode but it seems simple and lightweight. It’s actually the only agent I could get Gemini 3 Flash and Pro to consistently use tools with without going into loops.