Hermes Agent Runs Kimi K3 in a Sandbox

The Show HN post titled Run Hermes Agent with Kimi 3 in a sandbox is a maintainer release for running Hermes Agents on Moonshot AI’s Kimi K3 model inside Sanbox, a hosted sandbox. It deals with a familiar agent question: how do you let a coding bot stay online, answer from Telegram, and still keep it away from your real machine? The useful answer is to run the agent in a disposable boundary, then use OpenAI Codex, OpenAI’s coding agent and CLI, to inspect the changes before you trust them. For Codex users, the interesting part is the codex review loop around the bot, not the chat interface itself.

See what the Show HN actually shipped

The project’s pitch is simple: you can run a Hermes Agent in Sanbox, connect it to Telegram, and skip the old home-lab move of keeping a Mac mini or spare machine online. The posted setup is short: create a Telegram bot token, sign up for Sanbox, connect a model provider key, create a Sanbox API key, then ask a coding agent such as Codex or Claude Code, Anthropic’s coding agent, to wire it up with the Sanbox CLI.

That is why developers cared. The demo removes the annoying part of agent experiments: hosting a long-running process somewhere that can receive messages, call a model, and touch code without turning your laptop into a pet server.

The trap is reading “less than 10 minutes” as “safe enough.” A fast setup still creates three sensitive surfaces: Telegram bot tokens, model provider keys, and whatever filesystem or network permissions the sandbox receives.

Put the boundary before the bot

A sandboxed agent is a coding agent that runs with controlled file, network, and secret access instead of inheriting everything from a developer’s machine. That boundary matters more than whether the agent is reached through Telegram, a CLI, or a web UI.

Telegram, Telegram Messenger Inc.’s messaging app, is a convenient control surface because it gives the agent an always-available inbox. It is also a new public edge. If the bot can trigger code changes, installs, or network calls, then the first design question is not “does it answer?” It is “what can it reach when it answers?”

A practical first boundary is boring and strong: one repo clone, one working directory, one narrowly scoped API key, and no production credentials. If the sandbox needs GitHub or package registry access, start read-only where possible and move to write access only after you have a review habit.

This is the same lesson behind physical agent controls like Codex Micro Makes Agent Control Physical: make the permission boundary visible before the agent feels routine.

Let Codex set up the repo rules

Codex fits this project best as the careful local engineer, not as a magic remote operator. Use it to inspect the Sanbox CLI changes, write repo instructions, and produce a review receipt after the Hermes Agent has done work.

For Codex CLI workflows, the durable rule belongs in AGENTS.md. That file tells Codex what conventions, tests, and boundaries apply inside the repository. If you are collecting examples under the related training topic, this is the kind of small repo rule worth keeping.

# AGENTS.md

## Sandbox agent rules
- Keep Hermes and Sanbox setup files inside `agent-sandbox/`.
- Do not commit Telegram bot tokens, Sanbox API keys, or model provider keys.
- Before proposing a change, run `git diff --stat` and the nearest relevant test command.
- Treat new network calls, background jobs, and secret reads as opt-in. Ask before adding them.
- End every review with a receipt: files changed, tests run, risks left, and next human decision.

The trap is putting task prompts where repo memory belongs. “Set up Hermes today” is a prompt. “Never commit bot tokens” is a repo rule.

Review the diff, not the chat

The safe review habit is to judge the filesystem diff and test output, not the Telegram conversation that produced them. A good OpenAI Codex CLI review asks for a small answer: review the current diff only, list risky files, call out secret handling, name the tests, and do not edit files unless asked.

A concrete flow looks like this. The Hermes Agent changes a webhook handler and adds a small config file. You pull the sandbox branch or inspect the working tree, then ask Codex CLI to review code changes for credential leaks, unexpected network calls, missing tests, and unclear setup instructions.

That is a better codex code review than asking “does this look good?” It gives the model a bounded job and gives you a receipt you can paste into a pull request.

The trap is letting the same agent both create the change and bless the change without a separate pass. You do not need a committee. You do need a second, boring review step.

Try it safely with this checklist

Copy this into the issue or scratchpad before you connect a Hermes Agent to Telegram. Keep the first run small enough that deleting the sandbox is cheaper than debugging it.

## Hermes Agent sandbox trial

Goal:
- Prove the agent can answer from Telegram and make one harmless repo change.

Access:
- [ ] Telegram bot token is new and disposable.
- [ ] Sanbox API key is new and scoped to this experiment.
- [ ] Model provider key has usage limits or a throwaway project.
- [ ] Sandbox sees only the test repo or `agent-sandbox/` directory.
- [ ] No production secrets are mounted.

Task:
- [ ] Ask the agent to update one README section or one test fixture.
- [ ] Do not allow package publishing, deploy commands, or database writes.
- [ ] Save the full diff.

Codex review receipt:
- [ ] Files changed:
- [ ] Tests or checks run:
- [ ] Secret-handling concerns:
- [ ] Network or background-job concerns:
- [ ] Human decision: keep, revise, or delete sandbox.

Try this when you want an always-on coding assistant for low-risk maintenance, repo housekeeping, or experiment branches. Skip it when the work needs privileged infrastructure access, production credentials, or fast human judgment about product behavior.

Common questions

• How should I use codex review with a sandboxed Hermes Agent?

  Use Codex as the second pass after the sandboxed agent makes a change. Ask it to review the diff only, check for leaked secrets, unexpected network calls, missing tests, and unclear setup steps, then produce a short receipt. Keep the first trial to one harmless file so the review is easy to verify.

• Can Codex CLI review code changes from a sandboxed agent?

  Yes, Codex CLI can review code changes if you bring the diff into a repo where Codex can inspect the files. The important boundary is procedural: have the Hermes Agent create the change, then ask Codex to review without editing. That separation makes the result easier to trust.

• Do I need a Mac mini to run this Hermes Agent setup?

  No, the Show HN post explicitly framed Sanbox as a way to avoid running a home machine for the agent. The agent runs inside Sanbox and can be reached through Telegram. You still need disposable credentials and a narrow working directory, because hosted does not automatically mean safe.

• When is this overkill?

  It is overkill for one-off local refactors or small scripts you can run directly in Codex CLI. The sandboxed Telegram setup starts to make sense when the agent needs to stay online, receive asynchronous tasks, or operate in an isolated repo clone without tying up your laptop.

• What should I watch before giving the agent more access?

  Watch the first three diffs for secret handling, dependency installs, network calls, and background processes. If the agent repeatedly changes setup files, expands permissions, or skips tests, keep it read-only or throw the sandbox away. A clean review receipt matters more than a clever demo.

Best ways to use this research

• Best for: developers testing always-on coding agents who want the convenience of Telegram without giving a bot their whole laptop.
• Best first artifact: a repo-level AGENTS.md rule that defines sandbox boundaries, review expectations, and secret-handling rules before the first agent task.
• Best comparison angle: compare local Codex CLI work with a hosted Hermes Agent by looking at permission scope, persistence, review friction, and cleanup cost.
• Best practical takeaway: treat the Show HN demo as a sandbox pattern. The durable workflow is not “chat with an agent”; it is “isolate, diff, review, then decide.”

Further reading

• OpenAI Developers — AGENTS.md guide
• OpenAI Developers — Codex CLI
• OpenAI Developers — Codex CLI features

Try one narrow loop

Create a disposable bot, give the sandbox one harmless repo task, and make Codex produce a review receipt before you keep anything. If that loop feels too heavy, the project is probably not ready for an always-on agent yet.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.