Skip to main content
tutorials·10 min read

Your First Agent with Hermes or OpenClaw: Install, Lock Down, Schedule

A practical first day with Hermes Agent or OpenClaw: one clean chat, one skill, and one scheduled pull request digest. Then the security settings to check before you connect a chat app.

By Pedro Pinho·October 4, 2026·Updated October 4, 2026

By the end, you will have one agent doing one useful job: checking open pull requests and CI health for a repository, then producing a morning digest. It can stay local or reach your phone through Telegram.

Two rules. First, get a clean chat working before you add skills, schedules or messaging. More tools on a broken base only hide the problem. Second, the agent runs commands as your user, so setup is security work.

Hermes or OpenClaw: which one first

Hermes Agent and OpenClaw cover much of the same ground. Both support messaging gateways, scheduled jobs and skills written as SKILL.md files compatible with the AgentSkills standard. Their emphasis differs.

  • Hermes suits people who live in the terminal. It has a classic CLI, a newer TUI and an explicit Blank Slate mode. You choose every capability that loads.
  • OpenClaw is centred on a Gateway and web dashboard. Its quick start can reuse an existing Claude Code or Codex CLI login. It also has broad chat channel support and pairing for unknown senders.
  • Hermes asks before dangerous commands and can run terminal work inside Docker. OpenClaw has a security audit command and treats each gateway as one trust boundary.

Our advice is simple. Pick Hermes if you want a minimal, explicitly opted in agent controlled from the terminal. Pick OpenClaw if you want a dashboard and a chat first assistant quickly. Neither is better in every setting.

Below we take the Hermes path in detail, then the OpenClaw route in brief.

Step 1: Install Hermes

On Linux, macOS or WSL2, use the official installer from the Hermes quickstart:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

On native Windows PowerShell:

iex (irm https://hermes-agent.nousresearch.com/install.ps1)

Then reload your shell, with source ~/.bashrc or source ~/.zshrc.

On Linux you need git, curl and xz-utils. The installer fetches Python, Node.js, ripgrep and ffmpeg itself. On macOS and Windows a desktop installer is the recommended route; the scripts install the CLI only. See the installation page for the platform details.

Step 2: Choose a model, and start from a blank slate

A fresh installation offers Quick Setup, Full Setup and Blank Slate. Quick Setup uses a Nous Portal subscription and OAuth. Full Setup exposes provider and tool choices. Blank Slate asks only for a provider and model, then enables File Operations and Terminal.

Blank Slate leaves out web access, browser control, code execution, memory, delegation, cron, skills, plugins and MCP. It writes an explicit toolset list, so a later update does not quietly load tools you never selected. We think this is the right start. You add each capability when you need it, and you know why it is there.

hermes setup

If you would rather use the Nous Portal subscription route, this is the fast path. It turns on more tools for you:

hermes setup --portal

You can change the provider and model interactively at any time:

hermes model

Providers include Nous Portal, an OpenAI Codex subscription, Anthropic and OpenRouter. A Custom Endpoint covers vLLM, SGLang, Ollama or any OpenAI compatible API.

The model needs at least 64,000 tokens of context, or Hermes refuses to start. For a local model, the docs suggest -c 65536 on Ollama or --ctx-size 65536 on llama.cpp.

Secrets live in ~/.hermes/.env and everything else in ~/.hermes/config.yaml. hermes config set writes each value to the right file. This one moves terminal commands into Docker:

hermes config set terminal.backend docker

Step 3: Prove a plain chat works

Open the recommended TUI from inside the repository you want to inspect:

hermes --tui

Give it a small, verifiable task: Summarise this repository in five points. Name the main entry point and cite the files that support your answer.

Check those files yourself. You are testing the model, the file tools and the judgement in one go. Leave provider routing and fallback off for now.

Close it and resume the session with hermes --continue, or hermes -c for short. If it comes back, sessions are being saved.

If the session fails or behaves strangely, begin with:

hermes doctor

Then check the model choice again with hermes model. Fix the base provider before you go further.

Step 4: Write the digest as a skill

Blank Slate turned skills off, so turn them back on first. Run hermes tools, enable the skills toolset, then pick the cron platform in the same screen and give it only what the digest needs: Terminal and File Operations. Scheduled runs use that cron toolset, so keep it small.

A Hermes skill is a SKILL.md file in its own folder under ~/.hermes/skills/. The agent sees the short description and loads the full procedure only when needed. Each skill also becomes a slash command. The skills documentation describes the format and security checks.

Create a skill called pr-digest. Its SKILL.md should contain the following structure:

  • name: pr-digest
  • description: Produce a concise digest of open pull requests and their CI state for the current repository.
  • Trigger conditions: Run when asked for an open pull request and CI health digest.
  • Step 1: Use the GitHub CLI already installed and logged in by the user.
  • Step 2: List open pull requests.
  • Step 3: Report the CI status for each pull request.
  • Step 4: Flag pull requests with failing checks or no recent activity.
  • Step 5: Return a short factual summary.
  • Pitfalls: Do not merge, close, edit or comment on pull requests.
  • Verification: Confirm that every reported pull request is open and every CI state comes from the current repository.

The GitHub CLI is your own choice here, not part of Hermes. Install it and sign in before the first run.

Published skills install with hermes skills install, after a security scan. Read them anyway. If you let the agent write its own skills, set skills.write_approval: true in the configuration. Writes are then staged for review through /skills pending, /skills diff and /skills approve.

Step 5: Schedule it, paused first

Hermes cron runs inside the gateway, which checks for due jobs every 60 seconds. Install the gateway as a user service:

hermes gateway install

Create the first job paused. Replace the work directory with an existing absolute path:

hermes cron create "every 1d at 09:00" "Check this repository. Use the pr-digest skill to list every open pull request, report its current CI health, and flag items with failing checks or no recent activity. Do not change local or remote state. If there are no open pull requests, reply only [SILENT]." --workdir /home/me/projects/acme --skill pr-digest --paused --paused-reason "Awaiting review"

The prompt is deliberately self contained. Every cron run starts a fresh session with no memory of earlier runs, so the prompt has to say everything. The work directory also controls where file and terminal tools run, and loads AGENTS.md, CLAUDE.md or .cursorrules found there.

Find the job identifier, then trigger one controlled run:

hermes cron list

hermes cron run <job_id>

Local delivery is the CLI default. Inspect the saved result under ~/.hermes/cron/output/. A response containing [SILENT] suppresses delivery but remains saved locally. Failed jobs are always delivered.

Check scheduler health before enabling repetition:

hermes cron status

hermes cron doctor

The doctor command is read only. If you want to keep the digest local, resume the job once the output is correct:

hermes cron resume <job_id>

For phone delivery, configure Telegram through the messaging gateway:

hermes gateway setup

hermes gateway status

Then retire the local canary:

hermes cron remove <job_id>

Run the same hermes cron create command again. Drop --paused and --paused-reason, and add --deliver telegram.

Hermes scans scheduled prompts for prompt injection and credential theft patterns when you create them. Read the cron documentation before you give scheduled runs more tools.

The same job on OpenClaw

OpenClaw needs Node.js 24.16+ or 26.1+, and an existing Claude Code or Codex CLI login or a provider API key. The getting started guide covers the details.

Install it on macOS or Linux:

curl -fsSL https://openclaw.ai/install.sh | bash

On Windows PowerShell:

iwr -useb https://openclaw.ai/install.ps1 | iex

The installer starts onboarding. You can run it again later with openclaw onboard. Quick start detects existing AI access, verifies it with a real completion and opens the dashboard with a foreground Gateway. It defaults to an agent named main with full access. For this use case, we prefer Custom setup because it keeps the access decision visible.

After testing one plain chat, stop the foreground process with Ctrl+C and install the background gateway:

openclaw gateway install

openclaw gateway status

openclaw dashboard

The status should show the gateway listening on port 18789. If something is wrong, openclaw doctor reads the findings and openclaw triage turns them into a diagnosis.

Put the same SKILL.md in <workspace>/skills, which has highest precedence. OpenClaw skills require at least a name and description in YAML frontmatter. Treat registry skills as untrusted code and read them before enabling them, as the skills documentation advises.

Telegram is the fastest documented channel to configure. With the pairing policy, the bot answers your first message with an eight character code. Approve it on the machine that runs the gateway:

openclaw pairing list telegram

openclaw pairing approve telegram CODE

That grants direct messages only, not group access. See the pairing docs. Use the automation documentation to create a recurring isolated digest job and choose chat, webhook or no delivery. The management commands are:

openclaw automations list

openclaw automations runs <job-id>

Security before you connect a chat app

Both projects publish their security model: Hermes and OpenClaw. Read them. The short version:

  • Keep Hermes approvals in smart or manual mode. Never use --yolo or /yolo for routine work.
  • Leave approvals.cron_mode at its default deny setting. Dangerous scheduled commands will then be blocked.
  • Add permanent deny patterns for commands that should never run, such as git push --force*. These remain blocked even in yolo mode.
  • Use the Docker terminal backend for a production Hermes gateway. Local execution has no isolation. SSH can move execution to another machine.
  • Protect Hermes secrets with chmod 600 ~/.hermes/.env. Never run the gateway as root.
  • Set messaging allowlists such as TELEGRAM_ALLOWED_USERS, or approve people with hermes pairing approve telegram CODE. Hermes denies everyone when no allowlist exists. Never set GATEWAY_ALLOW_ALL_USERS=true in production.
  • Remember that file write guards are not a sandbox. Terminal commands still run as the same operating system user.
  • Run openclaw security audit to check OpenClaw configuration drift.
  • Keep one trust boundary per OpenClaw gateway. For mixed trust, use separate gateways, credentials and preferably separate operating system users or hosts.
  • OpenClaw binds to loopback on a normal host install, but container images default to an exposed bind. Pair that with authentication. An agent with message tool access can also send across conversations and channels by default.

What to do next

Once the digest runs cleanly, add one layer at a time. Tighten the wording of the skill. Add a second repository. Only then think about web search, memory or MCP servers, and read each skill before you install it.

One job that works beats ten that half work. Keep the scope narrow. Keep the output easy to check. Keep the security boundary where you can see it.

ai agentshermes agentopenclawagent skillsautomationsecuritytutorial

Share this article