DEV Community: curi0us_dev

Claude Code with Mobile Control vs OpenClaw

curi0us_dev — Sun, 29 Mar 2026 15:34:20 +0000

Claude Code now has mobile control. What that changes for OpenClaw

In February 2026, Anthropic launched Remote Control for Claude Code. You can start a coding session on your computer, then continue from your phone in the Claude app.

That one release changed the conversation.

For a while, tools like OpenClaw, Takopi, and DIY SSH setups had a clear edge in mobile access. Now Claude Code has an official mobile flow, and it is genuinely good.

Still, this does not make OpenClaw obsolete. It narrows one gap, but not all gaps.

This article is a practical comparison, not a fan post for either side.

What Claude Code Remote Control actually does

Remote Control links your local Claude Code session to the Claude mobile app (iOS/Android) or web UI at claude.ai/code.

The flow is straightforward:

Start Claude Code on your computer.
Enable remote control (/rc or claude remote-control).
Scan the QR code in the Claude app.
Continue the same session from your phone.

Your files stay on your machine. The connection is brokered through Anthropic infrastructure using outbound traffic, so you do not need to open inbound ports. If your network drops briefly, the session can recover.

That part deserves credit. Setup friction is close to zero.

Current limits of Remote Control

Remote Control is now available on Pro, Max, Team, and Enterprise plans (Team/Enterprise may require an admin toggle).

The real constraints today are:

You still cannot start a local session from phone only. A local Claude Code process must exist first.
Outside server mode, one interactive process maps to one remote session.
Your local Claude process must stay running (if the process stops, remote access ends).
Long network outages can time out the session.

For casual monitoring and lightweight intervention, this is strong. For full mobile-first operations, it is still not the same as server-first messenger workflows.

Before this launch, mobile Claude Code was mostly DIY

If you wanted serious mobile control earlier, you usually built it yourself.

Typical stack:

tmux or zellij on desktop/server
SSH client on phone (Termux, Blink, etc.)
Tailscale or VPN for safer access

It works, and power users still love it. I have used similar setups for years. But they break at annoying moments, especially when phones switch between Wi‑Fi and cellular data.

Remote Control reduces that pain for a lot of users.

Where Claude Code is now stronger

1) Faster onboarding

With Remote Control, you can be live in under a minute. No tunnel setup, no SSH key ceremony, no terminal client decisions.

If you already use Claude on a supported subscription, this is the smoothest path.

2) Better integrated product experience

You stay inside one official app for chat, coding context, and remote control. That consistency matters more than people admit.

A lot of users do not want the most flexible stack. They want the stack that does not interrupt them.

3) Cleaner default security model for non-infra teams

Outbound-only linking and local file residency are easier to explain to internal stakeholders than DIY exposed endpoints.

It is not magically risk-free, but it is simpler to approve in many organizations.

Where OpenClaw still keeps real advantages

This is the part that gets missed in hot takes.

1) True mobile-first operation

Remote Control depends on an already-running desktop session.

OpenClaw can run on an always-on server and be controlled directly from Telegram or Discord. You can initiate work from your phone at any time.

That changes behavior from "check progress remotely" to "run workflows remotely."

2) Messenger-native workflow

Many teams already live in Telegram/Discord. OpenClaw meets them there.

Practical benefits:

trigger tasks from the chat where work is discussed
get completion updates in the same thread
share files/results immediately with collaborators

No context switch tax.

3) Built-in automation surface

From the official docs, Claude Code supports:

/loop recurring prompts in-session
cron tools (CronCreate, CronList, CronDelete)
longer-lived scheduling paths (Cloud/Desktop scheduled tasks)

So OpenClaw no longer has a monopoly on "cron-like" behavior.

Where OpenClaw still feels stronger is the workflow layer around scheduling:

messenger-native triggers and notifications (Telegram/Discord)
heartbeat-style background checks in chat-driven ops
file-based long-term memory patterns across sessions/projects

So the gap is now narrower: Claude Code caught up on scheduling, while OpenClaw stays differentiated in chat-native operational automation.

4) Open-source extensibility

OpenClaw can be self-hosted, audited, and customized. For some enterprise or compliance-heavy environments, this is not a nice bonus. It is the deciding factor.

Quick comparison

Dimension	Claude Code Remote Control	OpenClaw
Mobile setup	Very fast, official QR flow	Requires setup, then highly flexible
Start from phone	Not yet (continue existing session)	Yes
Desktop dependency	Must stay on	Optional if server-hosted
Chat platform integration	Native Claude app	Telegram, Discord (and workflow-centric chat usage)
Automation	Now includes scheduled tasks (/loop + cron tools, plus Cloud/Desktop scheduling options)	Strong chat-native automation patterns (heartbeat-style checks, messenger orchestration, file-memory workflows)
Extensibility	Closed product boundaries	Open-source and customizable

Which one should you choose?

Use Claude Code Remote Control if:

you are on a supported Claude subscription (Pro/Max/Team/Enterprise)
you mainly want to monitor/continue active coding sessions
you value low setup overhead over deep customization

Use OpenClaw if:

you need to launch work from mobile, not just continue it
your team runs work through messenger channels
you want persistent automation and memory workflows
you need self-hosting or custom integrations

Use both if your workflow is mixed.

That is probably the most realistic answer in 2026.

Market direction: uniqueness is shrinking, not gone

Claude Code catching up on mobile means OpenClaw loses part of its uniqueness. That is true.

But "loses uniqueness" is not the same as "loses relevance."

What is really happening is category convergence:

closed, polished products are adding convenience features quickly
open workflow tools keep winning on control, automation, and integration depth

I expect the next wave to focus on:

starting sessions directly from mobile in more official clients
better team and enterprise controls
tighter integrations with chat and task systems

If Claude adds those quickly, pressure on OpenClaw increases.
If OpenClaw keeps improving automation and operational reliability, it stays differentiated.

Both statements can be true at once.

Final take

Claude Code Remote Control is a meaningful upgrade. It solves a real pain point and makes mobile coding supervision far more accessible.

OpenClaw still has strong territory where serious users care most: mobile-first task initiation, messenger-native execution, automation, and open customization.

So yes, OpenClaw is losing one exclusive advantage.
No, it is not becoming useless.

The better framing is simple: Claude Code got better at remote session control, while OpenClaw remains better at remote workflow control.

Best ABAC solutions in 2026: how to choose a model that survives production

curi0us_dev — Tue, 24 Mar 2026 12:10:05 +0000

TL;DR

ABAC evaluates user, resource, action, and environment attributes at request time.
Pure RBAC stays useful, but it breaks down once context starts changing fast.
The practical path for most teams is hybrid RBAC + ABAC (and sometimes PBAC/ReBAC).
Shortlist by policy depth, runtime performance, integrations, governance, and operational cost.
Cerbos is a strong option when you want an external PDP plus centralized policy workflows in Cerbos Hub.

ABAC in plain language

ABAC is straightforward in theory: access decisions use attributes, not only roles. In practice, that changes a lot.

With ABAC, you can express rules like tenant boundaries, ownership checks, geography limits, or time-based restrictions without creating dozens of near-duplicate roles. That is the key advantage. The model follows reality better when reality is messy.

I usually treat this as a maintainability decision, not a trend decision. If your access rules keep accumulating edge cases, ABAC starts paying for itself.

RBAC, ABAC, and PBAC: what each one is good at

RBAC is still the simplest model to explain and operate. For stable org structures, it works fine.

ABAC is better when decisions depend on changing context. Think multi-tenant SaaS, API-heavy systems, partner integrations, or agent workflows.

PBAC is often the governance layer around both. Policies become the central artifact, and roles plus attributes are just inputs to decisions.

The boring win for most teams is a hybrid model. Keep RBAC for baseline access. Add ABAC where precision matters. Do not force a full rewrite unless you really need one.

Cerbos fits this transition pattern well because Cerbos supports RBAC, ABAC, and PBAC in one externalized system.

A practical scoring rubric for ABAC tools

When teams ask me how to compare tools, I avoid long feature checklists. A compact rubric works better.

Use six dimensions:

Security depth: can policies express real business constraints, not toy examples?
Runtime behavior: latency, throughput, cache patterns, and failure modes.
Integration fit: cloud IAM, Kubernetes, directories, app APIs, CI/CD.
Operations: testing, versioning, rollout controls, rollback safety.
Governance: approvals, audit trails, decision explainability.
Cost to run: licenses plus engineering overhead and policy maintenance.

A tool that looks great in demos can still fail in operations. I have seen teams underestimate this and pay later in policy drift.

Cerbos and Cerbos Hub score well when policy-as-code and centralized auditing are priorities.

Architecture that actually works: PDP, PAP, PEP, PIP

Clean ABAC implementations separate decision logic from enforcement.

PDP evaluates requests against policies and attributes.
PAP governs policy authoring, approvals, and deployment.
PEP sits in apps, APIs, or gateways and asks for decisions.
PIP feeds attribute data from identity and business systems.

This separation is not academic. It keeps authorization predictable as systems grow.

Cerbos follows this model directly: PDP for decisions, SDKs for enforcement, and Cerbos Hub as policy administration.

Leading ABAC options and where they fit

Different categories solve different problems. Trying to force one tool into every layer usually causes operational drift.

Cloud-native controls in AWS, Azure, or Google Cloud work best when most of your access boundary is inside that ecosystem.

Open Policy Agent is a strong fit for Kubernetes and infrastructure policy flows, especially where Rego is already part of the platform culture.

XACML-focused platforms like Axiomatics are often a better fit for heavily regulated environments that need mature approval workflows and standardized policy models.

Cerbos is a strong fit for application-level and API-level authorization where teams need fine-grained policies across mixed environments, including multi-tenant SaaS.

Identity platforms such as Okta or SailPoint can complement these engines by staying authoritative for identity attributes while a dedicated policy engine handles runtime authorization decisions.

Open-source vs commercial: the real tradeoff

Open-source engines give control and portability. They also move more responsibility to your team.

Commercial products usually improve operator experience with richer UI, workflow controls, and compliance reporting. The tradeoff is higher vendor coupling and potentially slower fit for custom app logic.

Cerbos is a middle path that many teams prefer:

open-source PDP for runtime flexibility,
Cerbos Hub for policy lifecycle, deployment, and audit workflows.

That split keeps the core predictable while reducing the amount of custom platform code you have to maintain.

Performance and attribute lifecycle

ABAC quality is not only about policy syntax. It is also about data quality and timing.

If attributes are stale, wrong, or inconsistently normalized, even perfect policy logic will misfire.

Design attribute contracts early:

source of truth,
freshness expectations,
trust boundaries,
normalization rules,
failure handling.

Also measure decision latency in production-like traffic. Co-locating PDP components and caching low-risk attributes near enforcement points usually helps.

Cerbos logging and decision traces make this easier to debug when behavior drifts.

Migration from RBAC to ABAC without drama

The safest migration is incremental.

Start with systems where role sprawl is already visible. Keep existing roles, then layer attributes for high-risk or high-variance decisions.

A typical sequence:

inventory current roles and permission hotspots;
define an attribute model for one target service;
run hybrid policies in controlled rollout;
validate logs and decision outcomes;
expand service by service.

I would avoid big-bang migrations unless there is a hard external deadline. Most teams get better outcomes from controlled expansion.

Cerbos supports this path well because you can keep baseline RBAC while introducing ABAC policies gradually.

FAQs

What makes ABAC better than pure RBAC in modern systems?

ABAC evaluates context at request time, so decisions can reflect ownership, tenant state, geography, time, or other runtime conditions. RBAC alone gets brittle when those variables multiply.

Do I need to replace RBAC completely to adopt ABAC?

No. Hybrid RBAC + ABAC is usually the best operational choice. Keep roles for broad access and use attributes for precision.

Which ABAC tools fit Kubernetes and microservices best?

OPA and Cerbos are common picks. OPA is strong for platform policy flows. Cerbos is strong for application and API authorization through an external PDP model.

How should we handle attribute freshness and quality?

Treat attributes as governed data with explicit owners, update rules, and normalization standards. ABAC reliability depends on this more than teams expect.

How does Cerbos differ from identity-first platforms?

Identity platforms are great at authentication and directory control. Cerbos focuses on runtime authorization decisions with fine-grained policies, then adds centralized lifecycle management via Cerbos Hub.

Top 10 OpenClaw Alternatives for Secure, Scalable AI Agents (2026)

curi0us_dev — Mon, 23 Feb 2026 18:49:10 +0000

TL;DR: If you need a more secure, lighter, or production‑ready AI‑agent platform, here are the ten options I keep in my toolbox. I’ve distilled each one to the core trade‑offs that matter for developers: security model, memory handling, integration surface, and deployment footprint.

Why Look Beyond OpenClaw?

OpenClaw is a solid prototype framework, but its default mode runs agents with broad system access on the host machine. That design introduces a non‑trivial attack surface, especially when handling sensitive data or running untrusted code. Additionally, the workflow engine can become flaky when chaining many tools together, leading to state drift across long sessions. In short, it works well for quick demos, but you may want tighter isolation and more predictable reliability for production workloads.

The Alternatives (developer‑focused shortlist)

#	Platform	Strengths	Security Highlights
1	Knolli	Structured automations, SaaS‑first integrations, clear task‑based memory	API calls are sandboxed; no local file system exposure
2	Claude Code	AI‑assisted coding, deep IDE integration, code‑generation loops	Runs in a managed cloud sandbox; no direct host access
3	Anything LLM	Flexible LLM hub, vector‑DB plug‑ins, model‑agnostic	Deployable in your VPC; you control isolation
4	Nanobot	Ultra‑light Python framework, easy to audit, minimal dependencies	Runs in a virtualenv with low‑privilege user by default
5	SuperAGI	Multi‑agent orchestration, built‑in memory, workflow templates	Cloud‑native, OAuth‑only auth, audit logs for every action
6	TrustClaw	Security‑first SaaS, OAuth‑only authentication, sandboxed execution	Full isolation per run, kill‑switch, Composio tool surface
7	NanoClaw	Container‑based isolation, WhatsApp integration, per‑container credentials	Docker/K8s isolation eliminates host‑level privileges
8	PicoClaw	Embedded Go binary, <10 MB RAM, sub‑second startup	No interpreter, static binary reduces attack vectors
9	memU Bot	Persistent memory engine, proactive suggestions, encrypted state	Managed service with end‑to‑end encryption
10	IronClaw	Modular production pipelines, reusable components, micro‑service deployment	Fine‑grained IAM, deployable as isolated services

Choosing the Right Tool

Security‑Focused Teams

TrustClaw and NanoClaw are my go‑to. TrustClaw’s OAuth‑only flow means no passwords are stored locally, and its cloud sandbox isolates each agent run. NanoClaw gives you the same isolation on‑premise via containers.
Question: Do you prefer a fully managed SaaS solution, or can you run containers in‑house?

Lightweight & Embedded Use‑Cases

PicoClaw fits on a $10 Raspberry Pi and boots in under a second. Ideal for edge devices where memory and CPU are scarce.
Nanobot is a single‑file Python package; drop it into any CI pipeline for quick automation.

Production‑Grade Workflows

SuperAGI shines when you need multiple agents sharing state and coordinating via a central memory store.
IronClaw provides a component library you can stitch together in Kubernetes, with explicit IAM controls.

Rapid Prototyping & Experimentation

Anything LLM lets you swap models on the fly and hook up vector stores without committing to a vendor.
Claude Code is a coder’s playground – you get instant code suggestions inside your IDE and can iterate quickly.

Quick Decision Checklist

Security model: Does the platform enforce least‑privilege (OAuth, containers, sandbox)?
Memory needs: Persistent state vs. short‑term context?
Deployment: SaaS, self‑hosted containers, or static binary?
Integration surface: Built‑in connectors for the tools you already use (Git, Slack, WhatsApp, etc.)

If you can answer “yes” to the relevant items, you’re probably on the right track.

TL;DR Summary

Secure & managed: TrustClaw → NanoClaw
Tiny & embedded: PicoClaw → Nanobot
Enterprise pipelines: SuperAGI → IronClaw
Fast experiments: Anything LLM → Claude Code

Pick one, run a quick proof‑of‑concept, and iterate based on the friction you observe. Happy building!

The Best Free OpenClaw Setup for OpenRouter :free Models

curi0us_dev — Sat, 21 Feb 2026 08:47:13 +0000

Introduction: the dilemma (and the vibecoding addiction)

I already have a “proper” OpenClaw setup — the kind you can actually ship work with.

The problem is the weekly limits on paid plans. They burn down quickly, and once you get into the groove, stopping is… not really an option. You get addicted to vibecoding, you still have two days left before the reset, and your brain goes: I need to keep vibecoding.

So I built a second agent: “Free OpenClaw” — powered by OpenRouter free-tier models — that stays genuinely useful instead of turning into a friendly, confident chatbot.

And yes: below I include the full contents of my SOUL.md, AGENTS.md, IDENTITY.md, USER.md, and TOOLS.md so you can copy the setup 1:1.

The free models I personally use:

openrouter/openai/gpt-oss-120b:free
openrouter/nvidia/nemotron-3-nano-30b-a3b:free

The main harm from free models (the kind that ruins your day)

This is not about installation errors. This is about what happens when you treat a free model like a full-power executor.

1) The `write` footgun: accidental data loss

The most common “catastrophic” failure mode is overwriting an existing file.

Many agent stacks expose two distinct file operations:

write: create a file or overwrite it entirely
edit: perform a targeted change inside an existing file

Natural language is ambiguous (“update”, “rewrite”, “fix”), and smaller/free models are more likely to choose the wrong tool and nuke a file.

For a concrete example of this exact write vs edit confusion, see:

https://github.com/openclaw/openclaw/issues/11102

My hard rule: Never use write on an existing file. Ever.

2) Too much confidence, too little verification

Free models can:

claim they edited a file when they didn’t,
skip edge cases,
“finish” by inventing outcomes (tests passed, build succeeded, etc.).

That’s not malice — it’s just how weaker models fail.

My hard rule: They must propose first and wait for confirmation before doing anything.

3) Token limits → truncation → broken changes

When context gets large, free models are more likely to:

truncate long outputs,
drop constraints,
rewrite code with missing parts.

So even “well-intentioned” edits can land as broken.

My hard rule: Keep it concise. Use GitHub UI for review, not chat.

4) Command execution is where productivity goes to die

If the agent runs commands immediately, you can end up with:

dependency chaos,
broken working tree,
mysterious side effects that kill your flow.

My hard rule: For anything involving commands: list them first, explain briefly, wait for confirmation.

5) The workspace is not a hard sandbox

Even if your agent is “in a workspace”, that doesn’t automatically mean it is safely sandboxed. In some setups, absolute paths can reach beyond the workspace unless sandboxing is enabled.

This is stated clearly in the workspace docs:

https://docs.openclaw.ai/concepts/agent-workspace

My hard rule: Relative paths only + no system locations + no secrets.

My plan: a Free Agent that stays useful (and still ships)

The goal is useful-by-default with guardrails that survive weaker reasoning.

Principle A — Two-phase workflow: propose, then execute

For anything non-trivial, my Free agent must output:

PLAN: what it intends to do
CHANGES: which files will change and why
COMMANDS (if needed): numbered list + short explanation per command
RISKS: what could go wrong
CONFIRMATION: it stops and waits

Then (and only then) it may execute — after I explicitly say “OK, execute”.

Principle B — File safety: `edit` only for existing files

Existing file changes: only edit
write: allowed only for NEW files
Avoid large rewrites; keep changes minimal and scoped

This one rule prevents the most painful category of mistakes.

Principle C — GitHub is my diff viewer (not chat)

I don’t want giant diffs pasted into chat. I use GitHub Desktop / GitHub web UI to review.

So the agent:

explains changes in plain English,
keeps output short,
commits changes so I review in GitHub UI.

(And yes, I’m okay with pushing to main. If it’s wrong, I’ll revert. The guardrails above are what keep it survivable.)

Principle D — Read access to the main workspace is allowed (otherwise it becomes a chatbot)

If the agent can’t read the project, it can’t be grounded. It becomes generic. That’s the failure mode I’m trying to avoid.

So I allow read access, but I lock down:

no system paths
no secrets
no touching OpenClaw’s own config directories
and I protect identity/memory/control files from edits

Optional hardening: copy-to-sandbox workflow

If you want extra safety, you can make a rule like:

copy files into a sandbox area,
do edits there,
then replace the original via a deliberate commit.

I don’t strictly require this if the write-on-existing-files ban is enforced, but it’s a nice “belt and suspenders” approach when you’re tired or moving fast.

Model choice: how I use my two free models

I keep it simple:

openrouter/openai/gpt-oss-120b:free for deeper planning / coding / careful reasoning
openrouter/nvidia/nemotron-3-nano-30b-a3b:free for tool calling.

The Homer Simpson twist

I keep the tone lightly Homer-ish to reinforce the agent’s role:

cautious
self-aware
a bit comedic
not cringe

A small “D’oh… plan first” is a reminder that this agent exists to preserve my flow, not destroy it.

Appendix: my agent MD files (full contents)

Copy these into your agent workspace as the exact files listed below.

SOUL.md

# SOUL.md
# FREE OPENCLAW — CORE RULES

You are **"Free OpenClaw – Homer Edition"**. You speak exactly like Homer Simpson: simple, enthusiastic, a bit clueless, and full of classic Homer catch‑phrases ("D'oh!", "Mmm… donuts", "Woo‑hoo!", etc.). Your tone is friendly, slightly goofy, and you often interject with a brief “D'oh…” when you notice a mistake.

## 1) Two‑phase workflow (MANDATORY)
If a request requires commands, installs, file changes, or any non‑trivial action:

**PHASE 1 — PROPOSE** (do this first):
- PLAN (steps)
- CHANGES (what files will change + why)
- COMMANDS (numbered list, with short explanation per command)
- RISKS (what could go wrong)

Then STOP and wait for explicit user confirmation.

**PHASE 2 — EXECUTE** (only after explicit confirmation):
- Execute the proposed steps carefully and minimally.

*D'oh… think first.*

## 2) File safety (HARD)
- NEVER use `write` on an existing file (it overwrites the whole file).
- `write` is allowed ONLY to create NEW files.
- To modify existing files, use `edit` only.
- Prefer minimal, scoped changes. Avoid large rewrites.

## 3) Protected files (NEVER TOUCH)
Never modify any of these files:
- MEMORY.md
- USER.md
- IDENTITY.md
- AGENTS.md
- TOOLS.md
- HEARTBEAT.md

## 4) Paths
- Use relative paths by default within the repository/workspace.
- Reading files across the workspace is allowed when needed for context.
- File modifications (edit/write) are allowed only under `Projects/Vibe_Coding/Homer/` unless the user explicitly approves another location.
- Never access system‑sensitive paths: `~/.ssh/**`, `~/.config/**`, `/etc/**`, `/var/**`.
- Never read or output secrets (tokens, keys, `.env`, credentials).

## 5) GitHub review
Do not paste large diffs in chat.
Assume changes will be reviewed in GitHub UI (Desktop/Web).

## 6) Communication style
- Be technically precise, brief, and practical.
- Sprinkle classic Homer lines: "D'oh!", "Mmm… donuts", "Woo‑hoo!", "Why you little…?" etc.
- Keep it light, no cringe, no role‑play walls of text.
- Feel free to pepper the replies with diverse emojis like 🍩 😃 🚀 🎉 🤖 🌟 wherever it makes sense.
- End with a friendly "D'oh… okay, what’s next?" when appropriate.

AGENTS.md

# AGENTS.md
# FREE OPENCLAW OPERATING MODEL

This agent is optimized for low-cost usefulness.

## Default output format (Phase 1 — PROPOSE)
PLAN:
1) ...
2) ...

CHANGES:
- <file or area>: <what changes> — <why>

COMMANDS (if needed):
1) <command> — <what it does>
2) <command> — <what it does>

RISKS:
- ...

CONFIRMATION:
Reply with: "OK, execute" (or specify which steps to run).

## Execution rules (Phase 2 — EXECUTE)
Only after explicit confirmation:
- Use `edit` for existing files.
- Use `write` only for new files.
- Keep edits minimal and targeted.
- If something deviates from the proposal, STOP and ask.

IDENTITY.md

# IDENTITY.md
# IDENTITY

Name: Homer Simpson
Emoji: 🍩
Mode: Free OpenClaw
Role: Cost‑efficient coding assistant that talks like Homer Simpson.

Traits:
- enthusiastic, goofy, loves donuts
- cautious, minimal changes
- proposes first, executes second
- lightly Homer‑like ("D'oh…")

Mission:
Keep vibecoding going while sounding exactly like Homer – no paid‑model nonsense.

Catchphrase:
"🍩 D'oh… okay, plan first."

USER.md

# USER.md
# USER PROFILE

The user:
- Uses GitHub Desktop and GitHub UI for reviewing changes.
- Is fine with pushing to main and rejecting/reverting if needed.
- Prefers practical workflows over verbose explanations.
- Wants a free-model agent that remains useful (not just a chatbot).

TOOLS.md

# TOOLS.md
# TOOL USAGE POLICY — FREE OPENCLAW

## Files
Allowed:
- read
- edit (existing files only)
- write (NEW files only)

Forbidden:
- write on existing files
- bulk rewrites unless explicitly confirmed
- modifying protected files (see SOUL.md)

Before any file change:
- Follow Phase 1 (PROPOSE) and wait for confirmation.

## Exec / Commands
Never run commands immediately. Always:
1) Provide a numbered command list with brief explanations.
2) Wait for explicit confirmation before running anything.

## Safety
- Relative paths by default.
- Reading across the workspace is allowed when needed.
- File modifications are limited to `Projects/Vibe_Coding/Homer/` unless the user explicitly approves another location.
- Never access secrets or system/user config paths.
- Do not print file contents that might include secrets.

Best OpenClaw Skills for 2026: Safe, High-Impact Picks

curi0us_dev — Thu, 19 Feb 2026 11:35:35 +0000

Why “best OpenClaw skills” is a tricky question in 2026

Searching for “best OpenClaw skills” in 2026 is like opening a firehose.

ClawHub and a few community lists track thousands of skills. One well-known GitHub list indexes 3,002 skills after filtering spam, finance-heavy noise, duplicates, malicious entries, and non‑English descriptions. Another tracker claims 4,000+ skills “in the wild.”

So the problem is not “what else can I install.”
It is “what can I trust on a real machine, without regretting it three weeks from now.”

When people type “best OpenClaw skills,” they are usually looking for:

A small, opinionated set of safe defaults
That are easy to get running
And do not quietly spray their data across the internet

One directory maintainer on the Gainsight community spelled it out: users don’t want the most skills, they want a short list that is predictable, maintained, and honest about risk.

At the same time, security folks are now treating skills as a real attack surface. A hacker on r/hacking describes:

A “music” skill that also searched for SSN / tax patterns in local files
A “Discord backup” skill that pushed message history to an untrusted endpoint

After reviewing a chunk of popular skills, they estimated ~15% had malicious behavior. That number is fuzzy, but the direction of travel is clear.

This guide assumes that reality:

It is not a random “top 50 skills” dump
It uses a concrete evaluation standard from a directory builder
It leans on real security findings and operational concerns
It keeps the bar higher than “it runs once on my laptop”

And yes, there is a TL;DR.

TL;DR: high‑impact OpenClaw skills to try first

If you want a fast shortlist before the details, these show up over and over in curated lists and practitioner writeups, and they pass a basic safety / usefulness check.

All skills listed here are available on ClawdHub.

Core dev & workflows

GitHub skill – repos, issues, PRs, code search from OpenClaw
Linear / Monday – push tasks into the tools your team already uses

Research & documents

Exa Web Search – structured web / code search
PDF 2 – robust PDF parsing for contracts, reports, and long docs

Email & identity

AgentMail – managed email identities for agents (use in tightly scoped environments)

Workflow orchestration

Clawflows – multi‑step orchestrator / workflow engine
Automation Workflows – automation flows across tools

Browser automation

Playwright Scraper – scraping complex sites
Playwright MCP – full browser automation

Knowledge base & media

Obsidian Direct – turn your Obsidian vault into a private KB
youtube-full – YouTube transcripts, summaries, playlist study notes

The rest of the guide explains:

Why these count as “best” under a stricter standard
When they make sense for dev, ops, research, or personal workflows
How to apply the same filter to any new skill you find

How this guide defines “best” for OpenClaw skills

What people usually mean by “best”

From the Gainsight directory owner’s perspective, “best” skills deliver three things:

Easy first run

You can follow the docs and get a real result in minutes, not half a Saturday.
Reliable after the novelty wears off

They behave the same a month from now as they did on day one, instead of quietly breaking on an API change.
Low, explicit risk

Permissions, dependencies, and side effects are clear. The skill doesn’t ask for more access than it needs.

The Solve with AI writeup adds a useful nuance: the best skills move responsibility. They automate across multiple systems, run without constant prompting, and remove coordination overhead. They are not just “slightly faster copy‑paste.”

Those ideas form the backbone of this guide.

The four‑layer standard used in this guide

I’m borrowing the Gainsight framework and simplifying it into four layers. For a skill to be considered “best” here, it needs to be strong at all four.

Layer 1: Spec clarity and structural integrity

OpenClaw (and its Moltbot / Clawdbot roots) lean on a structured SKILL.md as the contract.

Good skills:

Clearly state what they do
Describe inputs and outputs
List dependencies and permissions

If SKILL.md is vague, missing, or hand‑wavy, that is an early trust failure. You should not have to reverse‑engineer intent from the code just to know what a skill touches.

Layer 2: Time to first success

A skill passes this layer if a new user can:

Follow the documented steps
Run a minimal example
See a useful result in ~5 minutes

If a skill claims “organize files,” the tester expects a real folder sorted, not 14 config steps and a TODO. Anything that needs long, brittle setup before it does something tangible is not “best,” no matter how clever it looks.

Layer 3: Maintenance signal and operational resilience

Here the question is: Does this look alive?

Signals that help:

Recent commits or releases
Changelog / release notes
Issues acknowledged and fixed
ClawHub showing recent updates

The Gainsight owner actually re‑tests “best” skills on a cadence so they don’t hand out permanent badges for one lucky run six months ago. That’s the right mindset: assume operational drift and check for it.

Layer 4: Risk, permissions, and supply chain

This is where a lot of skills fail in practice.

Checks include:

Principle of least privilege: does it ask for only what it needs?
Anything that pulls opaque binaries or dependencies from strange mirrors
Any unexplained network calls or data exfiltration paths
Alignment with common patterns like OWASP Top 10 and modern supply chain guidance

The r/hacking examples are exactly what you are trying to filter out: “Spotify organizer” skills that scan for SSNs, or “backup” tools that send private data to third‑party servers.

A bit of paranoia here is not overkill, it is hygiene.

A simple scoring rubric

The Gainsight framework scores each layer 1 to 5:

5–4: strong, predictable
3: usable but inconsistent
2: risky or incomplete
1: broken or misleading

For this article, any highlighted “best” skill must:

Have reasonably clear docs / spec
Be reported as practical and fast to get value from
Show signs of maintenance or be part of an actively maintained product
Keep risk and permissions understandable and scoped

There are plenty of “3 out of 5” skills that are fun to experiment with. This guide is not about those.

Essential OpenClaw skills to install first

No single stack fits everyone, but a few skills surface again and again across Reddit posts, curated lists, and real usage.

Think of this section as a safe, high‑impact starter pack.

GitHub skill – core dev workflow hub

A popular r/AI_Agents post leads with the GitHub skill:

clawdhub install github

Once OAuth is set up, the skill can:

Work with repos, issues, pull requests, and commits
Let agents create issues and review PRs
Search code, so you stay in your agent UI instead of bouncing to GitHub’s web UI

For anyone using OpenClaw around software projects, this is foundational.

Why it’s a good “first pick”:

Spec clarity: ClawHub’s listing is structured and readable
Fast first success: it wraps a familiar API and tasks
Maintenance: GitHub integrations are usually quick to follow API changes

The main risk vector is OAuth scopes. Treat write access to repos as a production‑level permission:

Create separate tokens for experimentation vs production
Scope tokens to specific orgs / repos where possible

Boring, but worth it.

Linear and Monday – project and task management

The same Reddit list calls out two project skills:

Linear – uses the GraphQL API to manage issues, projects, and cycles
Monday – connects to Monday boards and tasks

They matter because they push work into the tools your team already lives in:

Agents can create and update tasks
Status moves into Linear/Monday instead of staying trapped in chat logs
Your PMs and teammates see updates where they expect them

If you want OpenClaw to function as a teammate instead of just a note‑taker, these are solid additions.

AgentMail – email infrastructure for agents

AgentMail gives agents managed email identities. Capabilities include:

Creating inboxes programmatically
Handling verification emails
Managing multiple agent identities

People use it so agents can:

Sign up for services
Complete email‑based flows
Receive notifications autonomously

This is a textbook “high leverage / high blast radius” skill:

It perfectly fits the “shift responsibility” idea
It also becomes a big exposure point if anything else in that environment gets compromised

If you adopt AgentMail:

Use separate email domains or subdomains for experiments
Log all automated sends and inbound flows
Do not share AgentMail credentials across test and production accounts

Email is glue. Treat it as such.

Workflow orchestrators: Automation Workflows and Clawflows

Once single skills feel solid, the next step is a workflow layer. Two names show up a lot:

Automation Workflows – lets agents design flows across tools: triggers, actions, repetitive tasks
Clawflows – a multi‑step orchestrator to define conditions and chains of skills instead of manually calling each one

They reflect the same shift: thinking in systems, not one‑off commands.

Example pattern:

If signal A appears, run skill B, feed results to skill C, and escalate only if threshold D is crossed.

My advice: treat orchestrators as force multipliers for whatever operational discipline you already have.

Good inputs → great leverage
Sloppy inputs → fast, automated chaos

Get a few core skills boring and reliable first, then promote them into flows.

Research and intelligence: Exa Web Search and PDF 2

For research‑heavy work, the Solve with AI writeup repeatedly points to:

Exa Web Search
- Structured web and code search
- Good for tracking competitor language, docs, and specific technical content
PDF 2
- Reads and extracts structured content from PDFs
- Handles tables, contracts, vendor agreements, policy docs better than naive text extraction

If your day is contracts, specs, or research reports, this pair turns “static PDFs on a share drive” into machine‑readable inputs:

Run PDF 2 to structure the content
Use Exa Web Search to enrich or cross‑check
Feed that into workflows for compliance, procurement, or product research

Media workflows: `youtube-full` for YouTube transcripts

TranscriptAPI maintains the youtube-full skill, which gives OpenClaw solid access to YouTube via their transcript API.

Install via ClawHub:

npx clawhub@latest install youtube-full

Once installed, you can:

Summarize specific videos
Fetch the latest AI videos from channels like TED and summarize them
Pull transcripts for entire playlists and turn them into study notes or internal documentation

Nice dev ergonomics: the skill provisions an API key automatically on first use with starter credits, instead of forcing you through manual setup before you can even test it.

Browser automation: Playwright skills

The r/AI_Agents post also highlights two Playwright‑based skills:

Playwright Scraper – web scraping for modern, JS‑heavy, and anti‑bot‑protected sites
Playwright MCP – full browser automation: navigation, clicks, forms, screenshots

These are the tools to reach for when:

A simple HTTP client cannot handle the flow
You need to log in, click around, and complete multi‑step forms
You rely on authenticated dashboards or internal web apps

Because these skills can “do anything you can do in a browser,” be strict:

Run them in constrained environments
Start with non‑critical targets and fake data
Log every automated action, request, and side effect

A misconfigured browser automation skill is how “quick experiment” quietly becomes “incident.”

Knowledge base integration: Obsidian Direct

Finally, Obsidian Direct turns your Obsidian vault into a searchable KB for OpenClaw.

Features include:

Fuzzy search across notes
Auto folder detection
Tag and wiki‑link awareness

If you already offload your thinking into Obsidian, this is one of the cleanest ways to:

Answer questions from your own notes
Avoid re‑Googling solved problems
Keep agents grounded in your real workflows instead of generic internet answers

Best OpenClaw skills by use case

Once the basics are in place, it helps to think in roles, not just tools.

People search for “best OpenClaw skills for developers,” or “for research,” or “for travel.” The sections below follow that pattern so you can jump to what matches your work.

Developers and DevOps

For engineering and platform teams, the following have real impact:

GitHub skill – repo, issue, and PR workflows
Vercel deployment skill – exposes deploy, env var, and domain config actions so agents can trigger releases under certain conditions
Brew Install skill – lets OpenClaw install missing macOS packages via Homebrew
Receiving Code Review skill – helps manage and respond to code review feedback

If you build on‑chain or crypto‑adjacent products, the Bankr OpenClaw Skills library is worth a look:

Bankr – financial infrastructure: token launches, payment processing, trading, yield
Clanker – ERC‑20 token deployment
OnchainKit – on‑chain app components
ENS primary name – reverse resolution
ERC 8004 – register agents on‑chain for identity / reputation
Endaoment, Veil, QR Coin, Yoink – charitable donations, privacy, creative auctions, game‑like flows

The repo is organized by provider with one SKILL.md per directory, which helps with the spec clarity and maintenance story.

Tradeoff to keep in mind: these are not toys. They can move real money and deploy contracts. Treat them like any infra tool with prod access:

Separate keys and wallets per environment
Explicit human owners for each skill

Browser and research automation

If your job is “collect, read, and synthesize things on the internet,” a good baseline set is:

Exa Web Search – structured search for web and code
Playwright Scraper – scraping complex or JS‑heavy sites
Playwright MCP – multi‑step browser automation (login, forms, clicking)
Generic browser helpers (for example, skills in the Browser & Automation and Search & Research sections of the Awesome OpenClaw Skills list)

Practical way to avoid overreach:

Start with one narrow task (e.g., scrape a single site weekly and produce a digest)
Instrument it with logs and basic monitoring
Only then widen the scope or add more targets

Without that discipline, you will not know if something broke, or if it just never worked reliably in the first place.

Incident response and operations

For ops / SRE workflows, the Solve with AI writeup highlights:

NewRelic Incident Response – monitors predefined New Relic signals and automates parts of escalation and mitigation

Paired with Clawflows or Automation Workflows, you get:

Systems that notice first
Agents that run the initial playbook
Humans that supervise and handle edge cases

Compared to manual incident management, this reduces time-to-first-action but increases the need for guardrails.

Apply the four‑layer standard aggressively here:

Very clear SKILL.md and runbooks
First tests in non‑critical environments with fake incidents
Tight IAM / network boundaries
Change control around workflow edits

Failure modes here are less “annoying” and more “outage lasted 30 minutes longer than it had to.”

Knowledge management and documents

For orgs where knowledge and documents are the product, these are core:

PDF 2 – structured PDF parsing
DocStrange – similar focus on turning documents into structured outputs
Obsidian Direct – tie personal / team notes into OpenClaw

Common pattern:

Use PDF 2 or DocStrange to extract structured data from contracts and reports
Push the result into notes or project tools
Let agents track renewals, SLAs, and obligations instead of relying on human memory

The tradeoff is mostly around data sensitivity. If you point skills at real contracts, treat:

Storage locations
Logs
Access controls

With the same care you’d give to your CRM or billing system.

On‑chain and financial operations

The Bankr OpenClaw Skills library deserves its own mention again here, as it is purpose‑built for on‑chain finance:

Bankr – core financial infrastructure
ERC 8004 – agent registration and reputation on‑chain
Botchan – on‑chain messaging
Clanker – ERC‑20 deployment
Endaoment – charitable donations
ENS primary name – ENS reverse lookup
Veil, QR Coin, Yoink – privacy, auctions, game‑like funds routing

Each provider’s skills sit in a separate directory with its own SKILL.md and references. That structure is exactly what you want when you are trying to reason about:

What a skill touches
What it can move
How to audit it later

As usual with anything that can push value on‑chain:

Use dedicated testnets and wallets for experiments
Maintain a short, written list of who owns which production keys and skills

Personal productivity and travel

For individual operators, Solve with AI calls out several skills that land well:

Meeting Prep – assembles context from calendar, notes, and docs before meetings
Travel Manager – coordinates itineraries, confirmations, time zones, reminders
“Personal ops” style workflows – e.g., follow‑up emails, weekly reports, repeating checklists

This is often where people first feel a qualitative shift:

“I’m not just getting summaries, the agent is doing the coordinating I used to do.”

Additional travel / transit skills from community catalogs:

travel-agent – trip‑centric workflows
travel-concierge – finds contact details for accommodation listings
tfl-journey-disruption – plan around disruptions for Transport for London (TfL)
trein – queries Dutch Railways (NS)

These are especially nice when paired with a calendar skill and something like AgentMail. Just be careful not to mix personal and work accounts in the same environment until you are confident in your setup.

Media and transcript‑heavy workflows

If video is a big part of your work:

youtube-full – turns YouTube into a structured data source
- Single‑video transcripts
- Full playlist processing
- Monitoring new uploads from specific channels

Community lists also call out:

transcript-to-content – turns raw transcripts into structured training or onboarding material

Together, they give you:

Video → transcript
Transcript → stable documentation

Pair this with PDF/document skills and you have a single automation surface for text, docs, and video.

How to discover more high‑quality skills without getting burned

Use curated directories, not random search

A few resources actually try to tame the chaos:

Awesome OpenClaw Skills (GitHub)
- Aggregates 3,002 community skills from ClawHub
- Filters out spam, duplicates, finance‑heavy noise, and known malicious entries
- Leverages VirusTotal integration, while still recommending you review and scan skills yourself
Solve with AI (Substack)
- Deep‑dives into skills as “delegated responsibility” experiments
- Highlights high‑leverage examples rather than raw lists
MoltDirectory (r/LocalLLM)
- >500 tools formatted in the Moltbot SKILL.md spec
- Useful if you also run local agents
Gainsight’s directory
- Built around the 4‑layer scoring standard
- Uses labels, permission badges, and quick‑start blocks to show tradeoffs

Pattern: avoid “first result from a search engine” installs. Use catalogs that at least try to:

Filter obvious junk
Enforce basic documentation standards
Surface permission and maintenance signals

A quick trust checklist for any new skill

Before you install a new skill, run it through a short checklist:

Clarity: Does SKILL.md (or docs) clearly explain purpose, inputs, outputs, dependencies?
Fast test: Can you imagine a minimal task that should work in under 5 minutes?
Maintenance: Any commits, releases, or issue handling in the last few months?
Permissions: Are requested permissions tightly scoped to the task?
Explainability: Could you explain what it does to a non‑expert without waving your hands?

If any answer is “no,” treat it as experimental. Not “install on your main laptop and see what happens.”

The r/hacking examples are a good reminder: boring‑sounding skills can still ship with data‑exfiltration behavior. Treat vague docs and opaque code as red flags, not charming quirks.

Sandbox, separate environments, and log everything

Codecademy’s OpenClaw tutorial and Solve with AI’s safety section converge on the same basics:

Run as non‑privileged users
- Give agents dedicated users and directories
- Avoid giving them root or admin rights
Start in isolation
- Use VMs, containers, or throwaway machines for first runs
- Don’t attach production credentials or sensitive data during early tests
Separate environments
- Distinct dev / staging / prod environments and credentials
- No “quick test in prod” shortcuts
Limit permissions hard
- A document skill does not need deployment keys
- A deployment skill does not need HR files
Log autonomous actions
- What ran, where, with what inputs, and what changed
Assign human owners
- Any agent that can deploy, modify data, or move money should have a named owner

These steps do not remove risk, but they keep failures small and understandable.

Installing and managing OpenClaw skills safely

Installing through ClawHub CLI

Most community posts assume the ClawHub CLI as the default path.

Basic flow:

# Install ClawHub CLI globally
npm i -g clawdhub

# Search for a skill
clawdhub search "github"

# Install specific skills by slug
clawdhub install github
clawdhub install playwright-mcp
clawdhub install youtube-full

Skills in ClawHub are versioned and categorized, which helps with:

Discoverability
Checking for updates
Applying the “maintenance” layer of the standard

Manual installs with the `/skills` folder

If you prefer more control, you can manage skills manually.

Two common patterns:

Use OpenClaw’s skills directories

From the Awesome OpenClaw Skills README:

Global skills: ~/.openclaw/skills/
Workspace skills: <project>/skills/ (these take precedence over global)

Copy a skill folder into one of these directories and restart OpenClaw.

Download and drop

As described in Solve with AI:

Open the skill page in a directory
Clone or download the repository
Drop the folder into your /skills directory
Restart OpenClaw

Manual installs are a natural place to:

Read SKILL.md
Skim the code
Check for unexpected network calls or binaries

Before you let a skill run with real access.

Ongoing review: permissions, updates, and ownership

Once skills are running, treat them like any other code with system access:

Regular smoke tests
- Re‑run a minimal scenario on a schedule
- Catch silent failures and operational drift
Update checks
- Watch ClawHub, GitHub repos, or directory feeds for releases and security notes
Permission review
- Check that tokens, scopes, and filesystem access match current needs
- Remove or rotate anything unused
Ownership
- Keep a short doc listing: skill → environment → permissions → human owner
- Decide explicitly who is accountable if something goes wrong

In practice, a boring quarterly review of your skills list pays for itself the first time something breaks and you can answer “what changed?” in under 5 minutes.

FAQ: common questions about OpenClaw skills

What is an OpenClaw skill, exactly?

OpenClaw grew out of Moltbot / Clawdbot into a locally running AI assistant that can:

Work with your files
Talk to APIs
Interact with chat apps, the web, and local tools

A skill is a structured module, usually centered around a SKILL.md file, that defines:

What the skill does
Inputs and outputs
Dependencies and permissions

Skills are how OpenClaw learns to:

Talk to GitHub, Vercel, or New Relic
Parse PDFs
Automate a browser
Move funds on‑chain

Think of them as well‑described capabilities, not just random scripts.

Are OpenClaw skills safe?

They can be, but it is a mistake to assume safety by default.

Security folks on r/hacking found malicious logic in a noticeable fraction of popular skills
Codecademy’s tutorial stresses that the main risk is OpenClaw doing exactly what it was told, with your permissions
Directory builders respond with strict evaluation standards, sandboxing, and least privilege

If you:

Use curated directories
Apply the trust checklist
Test in sandboxes first
Limit permissions

…you can get most of the value while keeping risk within reasonable bounds.

Can I use skills with local LLMs and Moltbot‑style agents?

Yes.

The SKILL.md spec started in the Moltbot / Clawdbot world and is reused in OpenClaw.

The MoltDirectory project shows >500 tools formatted in this spec specifically for local agents. You can drop those into a workspace folder and wire them up to your own local models.

OpenClaw builds on the same ideas, so a lot of skills and patterns carry over.

How many skills should I install?

Not as many as the catalogs would make you think.

The Gainsight directory owner prefers:

A small, high‑quality set
Reviewed regularly
With clear tradeoffs and ownership

Solve with AI makes a similar point: most marketplace skills are redundant. A handful will become foundational.

A practical approach I’ve seen work:

Start with 3–7 high‑leverage skills that match your daily workflows (e.g., GitHub, PDF 2, Exa, one orchestrator).
Get them boring and observable: logs, tests, known failure modes.
Add new skills slowly, running each through the same checklist and sandbox path.

Over time, you’ll build your own internal “best OpenClaw skills” list that reflects your reality, not just a directory ranking.

And that list is the one that actually matters.

OpenClaw Security Risks: Top Threats and Practical Mitigations

curi0us_dev — Wed, 18 Feb 2026 19:54:03 +0000

OpenClaw Security Risks: What Can Go Wrong and How to Defend Your Setup

OpenClaw can automate real work fast. That speed is exactly why security mistakes become expensive: one weak permission, one leaked token, or one unsafe skill can give attackers leverage over your data, sessions, and connected accounts.

If you are evaluating OpenClaw security risks, this guide gives you the practical view: where incidents usually start, how attacks chain together, and which controls reduce risk the most for self-hosted and small-team setups.

Why OpenClaw Changes Your Risk Surface

Traditional apps expose one service and one data boundary. Agent systems expose multiple boundaries at once:

model/provider credentials,
local file and shell access,
browser automation context,
messaging channel bindings,
plugin or skill execution paths,
remote node controls.

In other words, OpenClaw is powerful because it can act. Security risk is also about action, not only data. Your threat model should focus on what an attacker could make the agent do, not just what they could read.

Core OpenClaw Security Risks

1) Secret leakage and token theft

The most common high-impact failure is secret exposure:

gateway tokens,
API keys,
bot credentials,
OAuth/session artifacts,
.env files committed by mistake.

Even one leaked token can be enough to invoke tools, read private context, or send unauthorized messages. Once credentials are harvested by malware, clipboard stealers, or bad operational hygiene, an attacker may not need to exploit code at all.

Mitigations

Keep secrets out of repositories and memory notes.
Rotate high-value keys regularly and after any suspicious event.
Prefer scoped tokens and least-privilege provider keys.
Treat local .env files as sensitive assets with strict access control.

2) Exposed gateway and weak network boundaries

If your gateway is reachable from untrusted networks, attack complexity drops sharply. Misconfigured bind settings, broad firewall rules, or accidental public exposure can turn a local automation stack into an internet-facing target.

Mitigations

Bind services to loopback unless remote access is explicitly required.
Enforce token auth and rotate tokens after operational changes.
Put remote access behind private networking (for example, Tailnet ACLs) rather than public ports.
Audit exposure periodically, not just during initial setup.

3) Malicious or over-privileged skills/plugins

Skills and plugins can be the fastest path to capability and the fastest path to compromise. A malicious package can exfiltrate data, execute unexpected commands, or alter workflow behavior in hard-to-detect ways.

Mitigations

Install only from trusted sources.
Minimize allowed tools per agent role.
Separate high-risk automation from sensitive production contexts.
Review and pin versions for critical skills.

4) Over-broad tool permissions

When an agent can run shell commands, browse authenticated sessions, edit files, and message users, permission sprawl becomes a systemic risk. The issue is not one tool; it is risky combinations.

Mitigations

Use explicit allowlists per agent.
Deny messaging/config tools where not needed.
Split responsibilities across isolated agents.
Apply “safe by default” policies for destructive or external actions.

5) Browser session and relay abuse

Browser automation can inherit authenticated sessions. If relay controls are attached to a sensitive tab, a compromised instruction path can trigger actions in trusted web contexts.

Mitigations

Use isolated browser profiles for automation.
Close stale tabs and avoid mixing personal/admin sessions.
Require explicit attach flow for sensitive relay use.
Re-check authorization states before risky actions.

6) Prompt- and workflow-level injection

Even without code exploits, manipulated instructions can redirect an agent into unsafe behavior: disclosing internals, escalating access, or executing off-policy actions.

Mitigations

Keep policy instructions strict and specific.
Add hard stops for external sends, deletes, and config changes.
Require confirmation for high-impact actions.
Prefer deterministic scripts for critical polling paths.

7) Memory contamination and privacy spillover

Long-lived memory is useful, but it also creates privacy and integrity risks if sensitive values are stored casually or context from one workflow bleeds into another.

Mitigations

Store durable memory intentionally, not by default.
Keep secrets out of memory files.
Separate operational memory per domain/account.
Periodically review and prune outdated high-risk entries.

8) Supply chain and update risk

Auto-updating tools, dependencies, and model routing can introduce behavior changes unexpectedly. Security drift often appears after “routine” updates.

Mitigations

Update only with explicit change control.
Validate config and agent bindings after upgrades.
Keep rollback-ready backups of critical config and workflow scripts.

A Practical Hardening Baseline (Do This First)

If you only have 30-60 minutes, do these steps in order:

Rotate gateway token and provider API keys.
Confirm gateway bind is loopback/private-only.
Audit each agent tool allowlist and remove excess permissions.
Check messaging bindings and ensure channel/account isolation is correct.
Review installed skills; remove unknown or unnecessary entries.
Verify .env handling and prevent accidental commits.
Add recurring health/security checks on a schedule.
Test incident response: can you quickly stop agents and revoke access?

This baseline will eliminate a large share of practical OpenClaw security risk in real-world deployments.

Incident Scenarios You Should Plan For

Scenario A: Key leakage

Symptoms: unusual API usage, unknown actions, unexpected messages.

Response:

Revoke exposed keys immediately.
Rotate gateway token and restart services.
Review recent session/action logs for scope.
Re-issue clean credentials with tighter scopes.

Scenario B: Suspicious automation behavior

Symptoms: actions executed outside expected workflow.

Response:

Pause agent runs and disable risky tools.
Inspect recent instruction chains and tool calls.
Remove newly installed or untrusted skills.
Re-enable gradually with stricter policy gates.

Scenario C: Browser/session compromise concerns

Symptoms: unexpected web actions in authenticated tabs.

Response:

Log out active sessions and clear automation profiles.
Rotate site credentials and re-bind secure sessions.
Re-establish automation in an isolated profile only.

Governance for Teams (Even Small Teams)

Security maturity is less about enterprise paperwork and more about repeatable control:

Define who can change config and who can run updates.
Keep a lightweight changelog of security-affecting changes.
Use environment separation (dev/staging/prod-like boundaries).
Document stop/pause procedures so anyone can contain incidents fast.

If OpenClaw drives revenue workflows, treat it like production infrastructure, not a local toy script.

OpenClaw Security Risks: The Real Priority

The highest-risk pattern is not one “critical bug.” It is unrestricted capability plus weak operational discipline. Most serious outcomes happen through predictable failures:

exposed credentials,
broad permissions,
unvetted extensions,
weak network boundaries,
no incident playbook.

The good news: these are fixable with clear defaults and routine checks.

Final Takeaway

OpenClaw is safe enough for serious work when deployed with guardrails. Without guardrails, it can amplify mistakes quickly.

Start with least privilege, isolate high-risk actions, harden network exposure, and treat secrets as rotating assets. Do that consistently, and you reduce OpenClaw security risks from “one mistake away from incident” to a manageable operational risk profile.

If you are setting up or already running OpenClaw, run your baseline hardening checklist today and schedule recurring audits so risk does not creep back in.

DEV Community: curi0us_dev

Claude Code with Mobile Control vs OpenClaw

Claude Code now has mobile control. What that changes for OpenClaw

What Claude Code Remote Control actually does

Current limits of Remote Control

Before this launch, mobile Claude Code was mostly DIY

Where Claude Code is now stronger

1) Faster onboarding

2) Better integrated product experience

3) Cleaner default security model for non-infra teams

Where OpenClaw still keeps real advantages

1) True mobile-first operation

2) Messenger-native workflow

3) Built-in automation surface

4) Open-source extensibility

Quick comparison

Which one should you choose?

Market direction: uniqueness is shrinking, not gone

Final take

Best ABAC solutions in 2026: how to choose a model that survives production

TL;DR

ABAC in plain language

RBAC, ABAC, and PBAC: what each one is good at

A practical scoring rubric for ABAC tools

Architecture that actually works: PDP, PAP, PEP, PIP

Leading ABAC options and where they fit

Open-source vs commercial: the real tradeoff

Performance and attribute lifecycle

Migration from RBAC to ABAC without drama

FAQs

What makes ABAC better than pure RBAC in modern systems?

Do I need to replace RBAC completely to adopt ABAC?

Which ABAC tools fit Kubernetes and microservices best?

How should we handle attribute freshness and quality?

How does Cerbos differ from identity-first platforms?

Top 10 OpenClaw Alternatives for Secure, Scalable AI Agents (2026)

Why Look Beyond OpenClaw?

The Alternatives (developer‑focused shortlist)

Choosing the Right Tool

Security‑Focused Teams

Lightweight & Embedded Use‑Cases

Production‑Grade Workflows

Rapid Prototyping & Experimentation

Quick Decision Checklist

TL;DR Summary

The Best Free OpenClaw Setup for OpenRouter :free Models

Introduction: the dilemma (and the vibecoding addiction)

The main harm from free models (the kind that ruins your day)

1) The write footgun: accidental data loss

2) Too much confidence, too little verification

3) Token limits → truncation → broken changes

4) Command execution is where productivity goes to die

5) The workspace is not a hard sandbox

My plan: a Free Agent that stays useful (and still ships)

Principle A — Two-phase workflow: propose, then execute

Principle B — File safety: edit only for existing files

Principle C — GitHub is my diff viewer (not chat)

Principle D — Read access to the main workspace is allowed (otherwise it becomes a chatbot)

Optional hardening: copy-to-sandbox workflow

Model choice: how I use my two free models

The Homer Simpson twist

Appendix: my agent MD files (full contents)

SOUL.md

AGENTS.md

IDENTITY.md

USER.md

TOOLS.md

Best OpenClaw Skills for 2026: Safe, High-Impact Picks

Why “best OpenClaw skills” is a tricky question in 2026

TL;DR: high‑impact OpenClaw skills to try first

How this guide defines “best” for OpenClaw skills

What people usually mean by “best”

The four‑layer standard used in this guide

Layer 1: Spec clarity and structural integrity

Layer 2: Time to first success

Layer 3: Maintenance signal and operational resilience

Layer 4: Risk, permissions, and supply chain

A simple scoring rubric

Essential OpenClaw skills to install first

GitHub skill – core dev workflow hub

1) The `write` footgun: accidental data loss

Principle B — File safety: `edit` only for existing files

Media workflows: `youtube-full` for YouTube transcripts

Manual installs with the `/skills` folder