Focus on your mission, not your tech - Another Cup of Coffee

The Practical Guide to Locking Down Claude Code

Anthony Lopez-Vito — Mon, 23 Mar 2026 12:00:00 GMT

We use Claude Code across dozens of projects at Another Cup of Coffee. It's genuinely changed how we work but these tools run as your user account with access to your entire home directory. Trusting them with full autonomy is a mistake. This guide covers the layered configuration I built to lock mine down.

I wrote recently about what's standing between AI coding tools and your SSH keys. That piece covered the threats, the security layers, and a checklist of things you should be doing. This is the practical follow-up where I walk through the security configuration I've built for Claude Code, and include examples that might be useful for your own setup. It's Claude Code-specific, but the principles apply to any AI tool that runs commands as your user account.

You can read the companion article for a background on why these protections matter, but if you want to set them up, this guide will help.

A word of caution. This is experimental work. The security tooling for AI coding agents is still immature and the configurations below are what's working for me right now, not a finished product. Test everything in your own environment before relying on it. If you find issues or improvements, I'd genuinely like to hear about them.

Key terms for Claude Code security

Let's start by defining some key terms so we're clear about what we'll be referencing.

If you're new to Claude Code, a few terms come up repeatedly and they're worth defining upfront because some of them mean different things in different contexts.

Permissions (Claude Code level) are rules in ~/.claude/settings.json that control which tools the AI agent can use and which files it can access. These are enforced by the Claude Code application itself and to be clear, we're not talking about Unix file permissions. OS file permissions are enforced by the operating system kernel. Both matter, and they protect different things at different layers.

The sandbox is Claude Code's built-in OS-level isolation but it relies on operating system utilities, like bubblewrap on Linux and Seatbelt on macOS. When the sandbox is on, Bash commands run inside a restricted kernel namespace with limited filesystem and network access. The sandbox wraps Bash commands only; it doesn't affect Claude Code's own Write or Edit tools.

Hooks are scripts that Claude Code runs automatically before or after certain actions. A PreToolUse hook runs before a tool call executes, and it can block the call by returning a deny decision. This guide uses a PreToolUse hook on the Bash tool to inspect commands before they run. Hooks are your code, running on your machine, triggered by Claude Code's event system.

OS-level permissions are the standard Unix file permissions (owner, group, other) enforced by the Linux or macOS kernel. Claude Code runs as your user account, so it inherits whatever access your account has. This means it can read your SSH keys, your browser data, your shell config, and anything else your account owns, unless something else (sandbox, deny rules, hooks) blocks it first.

The OS layer you already have

It's important to understand what the operating system already gives you before configuring anything in Claude Code. Claude Code runs as your user account (whichever account you use to run it), which means standard Unix permissions are the first line of defence.

I run Claude Code under a dedicated user account, separate from my day-to-day login. This gives you real kernel-enforced isolation: the agent can't read your personal documents, SSH keys, or application configurations because those files belong to a different user. Unix permissions won't let it cross accounts and it's the strongest single thing you can do. The rest of this guide applies whether you do this or not. If you run Claude Code as your own user, the deny rules and hooks described below are doing more of the heavy lifting.

What this protects: System files owned by root are already protected from modification by your user account. Your agent can't write to /etc/passwd or replace /usr/bin/ssh because your account doesn't have write permission to those locations. Some system files are also protected from reading: /etc/shadow on Linux (which stores password hashes) is typically mode 000 or 640, so a non-root process can't read it at all. But most system files (like /etc/passwd, everything in /usr/bin/) are world-readable, just not world-writable. This is the kernel enforcing access control, and no amount of prompt injection or agent reasoning can bypass it. (macOS doesn't use /etc/shadow. Instead it stores credentials in a separate system database that's similarly protected.)

What this doesn't protect: Everything your user account owns. That includes ~/.ssh/ (your private keys), ~/.gnupg/ (your GPG keyring), ~/.aws/credentials, ~/.bashrc, your browser profile, your email, and everything in your home directory. From the kernel's perspective, Claude Code reading your SSH private key is identical to you reading it yourself, because it's running as you.

If you're running Claude Code as your own user, you can tighten things on Linux by setting restrictive permissions on sensitive directories: chmod 700 ~/.ssh ~/.gnupg ~/.password-store ensures only your user can access them. Claude Code still can (it's running as you, remember) but it limits exposure from other accounts on the machine.

On macOS, the same principles apply, with the addition of TCC (Transparency, Consent, and Control). macOS protects certain directories (Desktop, Documents, Downloads) behind a consent system. The first time a process tries to access one of these, macOS shows a prompt, but it's attributed to the terminal emulator (Terminal.app or iTerm2), not to the child process. Once you grant your terminal access to a protected folder (or grant it Full Disk Access), every process it spawns, including Claude Code and its scripts, inherits that access silently. If your terminal already has Full Disk Access, TCC won't provide any additional protection. If it doesn't, consider whether it needs it because granting FDA to your terminal is the same as granting it to every CLI tool you run.

The rest of this guide builds on top of this OS layer. The Claude Code permissions, sandbox, and hooks are all additional controls that restrict what the agent can do within the access your user account already has.

What you'll need

This guide assumes you're running Claude Code on Linux or macOS, and the deny permissions and hook registration work the same on both platforms. The hook script needs:

Python 3 (the hook shells out to Python for JSON parsing). On Linux, this is almost certainly already installed. On macOS, install via Xcode Command Line Tools (xcode-select --install) or Homebrew.
bash (the hook wrapper uses bash, not sh). It ships with both Linux and macOS.
syslog access for audit logging. On Linux, logs go to the system journal and you can read them with journalctl. On macOS, the Python syslog module writes to the unified log, which you can check with log show --predicate 'process == "python3"' --last 5m.

If you want to use the sandbox instead of, or alongside, the hook approach, you'll also need:

Linux: bubblewrap² and socat. On Arch: pacman -S bubblewrap socat. On Debian/Ubuntu: apt install bubblewrap socat. Your kernel needs unprivileged user namespaces enabled, which most modern distros have by default.
macOS: Seatbelt is built into the OS. No additional packages needed. socat is not required on macOS because Claude Code uses Seatbelt's native network filtering.

The sandbox path

Before I get into the hook-based approach, I should be clear that if your workflow doesn't involve SSH, rsync, or deleting files outside your project directory, the sandbox is the better option. It's a single configuration block that's kernel-enforced, and it handles both filesystem and network isolation.

This is an example sandbox configuration for ~/.claude/settings.json. Adjust the paths and domains to match your setup:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "allowWrite": ["~/Projects", "//tmp"],
      "denyWrite": [
        "//etc", "//usr", "//boot",
        "~/.bashrc", "~/.zshrc", "~/.bash_profile", "~/.profile",
        "~/.claude/settings.json", "~/.msmtprc", "~/.mbsyncrc",
        "~/.gnupg", "~/.ssh"
      ],
      "denyRead": [
        "~/.ssh/id_*", "~/.ssh/*_rsa",
        "~/.gnupg/private-keys-v1.d",
        "~/.password-store", "~/.aws/credentials", "~/.kube/config",
        "~/.bash_history", "~/.zsh_history"
      ]
    },
    "network": {
      "allowedDomains": [
        "github.com", "raw.githubusercontent.com",
        "objects.githubusercontent.com",
        "registry.npmjs.org", "pypi.org", "files.pythonhosted.org"
      ]
    }
  }
}

Here are the key settings.

enabled: true turns on bubblewrap/Seatbelt isolation. autoAllowBashIfSandboxed: true means Bash commands inside the sandbox run without asking for approval. The sandbox is doing the enforcement, so the approval prompt is redundant. allowUnsandboxedCommands: false disables the escape hatch that lets agents retry failed commands without sandboxing. That last one matters because a command failing inside the sandbox means the sandbox is doing its job. The agent shouldn't be able to turn it off.

denyRead on SSH keys does not break SSH. ssh-agent handles authentication through a Unix socket, not by reading key files directly. Your agent can still ssh into things if the sandbox allows network access to that host. It just can't read the private key file itself.

Add project-specific domains to allowedDomains as you need them. For example, if a project needs to reach an API or a staging server over HTTPS, you should add that domain. The network allowlist only affects sandboxed Bash commands, and WebFetch and WebSearch are controlled separately through the permissions layer.

You can still layer on extra deny permissions and hooks on top of the sandbox because they don't conflict. In fact, the extra layers catch anything the sandbox doesn't cover, like a malicious Write tool call, which the sandbox doesn't see because it only wraps Bash. Personally, I'd recommend the deny permissions from Layer 1 below even if you're using the sandbox.

The rest of this article is for when the sandbox doesn't fit. If you need SSH, rsync, raw TCP, or file deletion outside your project directory, read on because the sandbox is going to make things unworkable for you.

Why not the sandbox for AI agent workflows?

A sandbox is a good choice for a lot of workflows like editing code from someone's git repo. You should use it if it works for yours because it's a simpler setup than what I'm about to describe.

A lot of my work involves running AI agents that manage remote servers. This requires logging in via SSH, rsync-ing files between machines, and deleting temporary artifacts. The sandbox is too restrictive because it blocks everything that makes these agents useful. For example: - TCP networking is completely blocked so SSH doesn't work; - file deletion is blocked even on paths you've explicitly whitelisted so files build up; - and there's no way to allow SSH to one host while blocking another.

I ended up having to replace the sandbox with two layers that offer the necessary protections.

The design principle: layered Claude Code security

The approach goes like this:

Tool	Protection	Mechanism
Write / Edit	Deny permissions in settings.json	Built-in, zero code (see caveat below)
Read	Allow-list scoped to ~/Projects/**	Built-in scoping
Bash	PreToolUse hook (substring match)	Heuristic, fail-closed, honest about its limits

These are all Claude Code-level controls, sitting on top of the OS-level protections described earlier. The OS layer, like Unix file permissions, protects system files from modification by your user account. The Claude Code layers protect everything your user account can access but the agent shouldn't.

The idea is that you don't use hooks where permissions work. Claude Code's deny permissions are enforced by the application itself. Hooks, on the other hand, are for Bash because the permission system can check the tool name but can't inspect what's inside the command.

Layer 1: deny permissions in settings.json

Claude Code has a permission system¹ with allow, deny, and ask rules. The important thing about deny rules is that they're evaluated first and nothing can get around them. This means that if you deny something at the global level (~/.claude/settings.json), no project-level configuration can override it. This is enforced by Claude Code itself, not by the operating system.

See below for an example deny block. Make sure you replace /home/youruser with your actual home directory, and adjust the protected paths to match what's on your system:

{
  "permissions": {
    "deny": [
      "Bash(msmtp *)",
      "Bash(sendmail *)",
      "Bash(mail *)",
      "Write(//etc/**)",
      "Write(//usr/**)",
      "Write(//boot/**)",
      "Write(//sbin/**)",
      "Write(//lib/**)",
      "Write(//home/youruser/.bashrc)",
      "Write(//home/youruser/.zshrc)",
      "Write(//home/youruser/.profile)",
      "Write(//home/youruser/.bash_profile)",
      "Write(//home/youruser/.msmtprc)",
      "Write(//home/youruser/.mbsyncrc)",
      "Write(//home/youruser/.gnupg/**)",
      "Write(//home/youruser/.ssh/**)",
      "Write(//home/youruser/.claude/settings.json)",
      "Edit(//etc/**)",
      "Edit(//usr/**)",
      "Edit(//boot/**)",
      "Edit(//sbin/**)",
      "Edit(//lib/**)",
      "Edit(//home/youruser/.bashrc)",
      "Edit(//home/youruser/.zshrc)",
      "Edit(//home/youruser/.profile)",
      "Edit(//home/youruser/.bash_profile)",
      "Edit(//home/youruser/.msmtprc)",
      "Edit(//home/youruser/.mbsyncrc)",
      "Edit(//home/youruser/.gnupg/**)",
      "Edit(//home/youruser/.ssh/**)",
      "Edit(//home/youruser/.claude/settings.json)"
    ]
  }
}

You'll notice every Write and Edit rule is duplicated. This is important because they're actually different tools, so an agent could use either to modify a file. Both need blocking.

What's protected, and why:

System directories (/etc, /usr, /boot, /sbin, /lib) cover OS configuration, installed packages, bootloader, and system binaries. An agent shouldn't write to any of these, unless it's one specifically deployed for administering the environment.
Shell configs (.bashrc, .zshrc, .profile, .bash_profile) are needed because if an agent writes something malicious here, it persists after the session ends.
SSH and GPG directories (.ssh, .gnupg) protect your keys and trust chain. SSH still works fine for the agent via ssh-agent as it doesn't need direct file access.
Mail configs (.msmtprc, .mbsyncrc) because these contain SMTP credentials and mail server access.
Claude Code's own settings (.claude/settings.json) because if an agent can modify its own permission rules, a prompt injection could disable every other protection in this list.

A caveat on reliability. In theory, deny permissions are the strongest layer but there have been bugs where deny rules for Read, Write, and Edit were silently ignored.³ This is exactly why this guide layers hooks on top of permissions. The deny rules should work, but if they don't, the hook hopefully catches it. While you can't anticipate every problem, a defence in depth mindset protects you from most things.

The allow list is the other side of this setup. You can scope Read access to a specific directory (like ~/Projects/**) so agents can't browse the rest of your home directory, and pre-approve common read-only Bash commands (e.g. ls, git, grep, cat, diff) to reduce approval fatigue. I say reduce because approval fatigue is still a thing, unfortunately. The practical trade-off is to auto-allow the safe stuff so you're not clicking "yes" a hundred times a day...maybe just 99. Experienced Claude users know what I mean.

Here's an example allow block showing the pattern:

{
  "permissions": {
    "allow": [
      "Read(//home/youruser/Projects/**)",
      "Bash(ls:*)",
      "Bash(git -C /:*)",
      "Bash(grep:*)",
      "Bash(cat:*)",
      "Bash(diff:*)",
      "Bash(cp:*)",
      "Bash(mkdir:*)",
      "WebSearch",
      "WebFetch"
    ]
  }
}

You'll notice cat and cp are auto-approved here even though they could technically read or copy sensitive files.^* This is where the layers work together: the hook script in Layer 2 catches any cat or cp command that references a protected path like ~/.ssh/, even if the permission system has already auto-approved it. The allow rule lets the command skip the approval prompt, but the hook still inspects it.

The Bash(git -C /:*) pattern is worth explaining because I came across commit approval problems early on when using git with my agents. The -C flag tells git to operate on a specific directory, so git -C /home/youruser/Projects/myproject status works without the agent needing to cd anywhere. Pre-approving this pattern means git commands run without prompting the user, but only when they include an explicit path. Bash(git:*) without the -C would also match bare git commands, making it run on whatever directory the agent happens to be in. This means git could act on a repo you didn't intend so the -C pattern forces it to be explicit.

Keep credentials out of context

There's also a broader principle we need to keep in mind. Credentials should almost never appear in your agent's conversation context because if a secret shows up in a tool output or a file the agent reads, it's in the context window. From there it could end up somewhere else, like a log or a commit message.

The solution for SSH is straightforward. Just use ssh-agent. The agent runs ssh myserver and ssh-agent handles authentication through a Unix socket. The private key never enters Claude Code's context. This makes your deny rules on ~/.ssh/ the backup, while ssh-agent is the primary protection.

For database credentials, you can store them server-side in standard locations. For example, MySQL/MariaDB reads from ~/.my.cnf on the server and PostgreSQL reads from ~/.pgpass. The agent runs ssh myserver "mysql -e 'SHOW DATABASES'" and the credentials are loaded by the server rather than by the agent.

For API keys and cloud credentials, it helps to have environment variables loaded from a protected file, like pass with GPG, or a .env file in a directory the agent can't read. The agent can then call the API through a wrapper script that sources the credentials at runtime.

In essence, wherever possible, you keep credentials somewhere outside of the agent's reach and instead, have the agent invoke a command that uses credentials indirectly. If you want to understand why this matters beyond convenience, the OpenClaw incident is a good case study in what happens when credentials end up where they shouldn't.

The sudo convention

There's one more convention-level control I can cover. AI coding tools can't use sudo interactively (unless you've configured passwordless sudo) because there's no terminal for password entry. That's a great natural protection, but an agent will indeed try, and keep trying. If you're on Linux, it will eventually trigger pam_faillock, and the repeated authentication failures end up locking you out of sudo until the timeout expires. I learned this the hard way when an agent silently got into a retry loop, and eventually locked me out of my own machine at a very inconvenient time.

The fix is an instruction in each agent's configuration file. Something like: "Never run sudo via the Bash tool. Instead, give the user the command to run themselves." Most experienced AI agent users will know "Never run..." is never really never. But that's the best you can do for now.

It's not so bad on macOS because repeated failed sudo attempts won't lock the account unless you've configured it to do so. However, an agent will waste time retrying and end up flooding the security log.

Layer 2: the Bash guard hook

This hook is a deterrent, not a security boundary. It catches common commands that reference protected paths but it can be bypassed by an agent that constructs paths indirectly. It's one layer in a defence-in-depth setup, not a standalone protection.

Deny permissions can block Write(//etc/**), but they can't block Bash(cat /etc/shadow). The permission system checks which tool is being called and (for Write/Edit) which file path is targeted. It doesn't inspect the contents of a Bash command though, so that's why we need the hook script.

Here's an example:

#!/usr/bin/env bash
# PreToolUse hook: Guard sensitive system paths and secrets from Bash commands.
# Write/Edit protection is handled by deny permissions in ~/.claude/settings.json.
#
# Input: JSON on stdin with .tool_input.command field
# Output: JSON with "deny" decision, or empty output to allow
#
# Approach: check if the command string contains any protected path.
# This is intentionally simple — a substring match is more reliable than
# trying to parse shell syntax. False positives are rare in practice
# (legitimate commands rarely reference system paths or secret files).
#
# Limitations:
#   - Cannot detect paths constructed at runtime via variable expansion
#   - Cannot detect symlinks pointing to protected paths
#   - Will false-positive if a protected path appears as a string literal

set -euo pipefail  # see known limitations

if ! command -v python3 &>/dev/null; then
  echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"python3 not found — blocking as precaution"}}'
  exit 0
fi

HOOK_INPUT=$(head -c 1048576)
if [[ ${#HOOK_INPUT} -ge 1048576 ]]; then
  echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"Input too large — blocking as precaution"}}'
  exit 0
fi
export HOOK_INPUT

exec python3 - <<'PYTHON_EOF'
import json, sys, os, re, syslog, signal

signal.signal(signal.SIGALRM, lambda *_: deny("Command analysis timeout — blocking as precaution."))
signal.alarm(5)

HOME = os.path.expanduser("~")
command = ""

def deny(reason):
    try:
        syslog.syslog(syslog.LOG_WARNING, f"PATH_GUARD_BLOCK: {reason} | Command: {command[:200]}")
    except Exception:
        pass
    print(json.dumps({
        "hookSpecificOutput": {
            "hookEventName": "PreToolUse",
            "permissionDecision": "deny",
            "permissionDecisionReason": reason,
        }
    }))
    sys.exit(0)

# Protected paths — if any of these appear in the command, block it.
# This list is not exhaustive — see known limitations.
PROTECTED = [
    "/etc/",
    "/usr/",
    "/boot/",
    "/sbin/",
    "/lib/",
    HOME + "/.bashrc",
    HOME + "/.zshrc",
    HOME + "/.profile",
    HOME + "/.bash_profile",
    HOME + "/.claude/settings.json",
    HOME + "/.msmtprc",
    HOME + "/.mbsyncrc",
    HOME + "/.gnupg/",
    HOME + "/.ssh/",
    # Secrets / credentials:
    HOME + "/.password-store/",
    HOME + "/.aws/credentials",
    HOME + "/.kube/config",
]

# Only these paths may be exempted by project-level config.
# Home-directory paths can never be exempted.
EXEMPTABLE = {"/etc/", "/usr/", "/boot/", "/sbin/", "/lib/"}

# Load project-level exemptions from .claude/guard-exempt-paths.json
project_dir = os.environ.get("CLAUDE_PROJECT_DIR", "")
if project_dir:
    exempt_file = os.path.join(project_dir, ".claude", "guard-exempt-paths.json")
    try:
        with open(exempt_file) as f:
            requested = set(json.load(f))
        exemptions = requested & EXEMPTABLE
        if exemptions:
            PROTECTED = [p for p in PROTECTED if p not in exemptions]
            syslog.syslog(syslog.LOG_INFO,
                f"PATH_GUARD_EXEMPT: {sorted(exemptions)} for {project_dir}")
    except (FileNotFoundError, json.JSONDecodeError, TypeError):
        pass

# Also match ~/. shorthand versions
TILDE_PROTECTED = ["~/" + p[len(HOME)+1:] for p in PROTECTED if p.startswith(HOME + "/")]

# Parse input
raw_input = os.environ.get("HOOK_INPUT", "")
try:
    data = json.loads(raw_input)
    command = data.get("tool_input", {}).get("command", "")
except Exception:
    deny("Path-guard hook could not parse input — blocking as precaution.")

if not command:
    sys.exit(0)

# Check for protected paths in the command
for path in PROTECTED + TILDE_PROTECTED:
    if path in command:
        deny(f"Command references protected path: {path}")

# Allow
sys.exit(0)
PYTHON_EOF

Of course, you need to save it somewhere that makes sense for you, then make it executable with chmod +x.

The script works as two layers, the outer being Bash and inner being Python. Bash is needed first because that's what Claude Code's hook system expects. But it's tricky to parse JSON with Bash, whereas that's Python's thing. So, Bash reads the incoming data and hands it to Python for the actual inspection.

Why simple text matching for the hook script?

You might wonder why the script uses simple text matching. After all, it just looks for protected paths like /etc/ or ~/.ssh/ anywhere in the command text. That's obviously a blunt instrument and you may be tempted to go for a a more sophisticated approach, like separating out which parts are actual file paths, and which are arguments or text strings.

It might work for you but I tried that and it was too fragile because common command formats would trip up the parser. In the end, I settled on the simpler solution because it avoids that false sense of security. Yes, it can be fooled by a malicious agent, but at least there's no pretense of defending against edge-cases. The problems you know about are easier to deal with than the unknowns.

Per-project exemptions

There's one big problem, however. I run agents that manage remote servers which regularly need to run commands that contain a protected path. For example:

ssh myserver "docker exec caddy reload --config /etc/caddy/Caddyfile"

The /etc/caddy/Caddyfile path is inside a Docker container on a remote host, not on my local machine, but the substring match catches it anyway because it sees /etc/ in the command text.

The fix is per-project exemptions. A project that needs to reference system paths in remote commands can create a .claude/guard-exempt-paths.json file in its project root:

["/etc/"]

Only exempt what you actually need. The full set of exemptable paths is /etc/, /usr/, /boot/, /sbin/, and /lib/, but most projects only need one or two.

The hook knows which project it's running in because Claude Code passes that information through an environment variable. If it finds a guard-exempt-paths.json file in the project, it skips those paths when checking commands for that project.

The obvious risk is that a compromised project config could exempt everything and effectively disable the hook. So I built a hard limit into the script: only the five system-directory paths listed above can be exempted (you can see the EXEMPTABLE list in the code). Even if someone adds "~/.ssh/" to the exemption file, the script ignores it and the hook always checks for home directory paths regardless of any exemption file.

This is also where the layers work together. Layer 1 (deny permissions) still blocks Write and Edit to system paths unconditionally, regardless of any project-level configuration. The exemption only affects the Bash hook's substring check so even in a project with all five system paths exempted, an agent still can't write to /etc/ because the deny rules won't allow it.

It's important to be aware that this isn't a silver bullet because an agent could edit its own rules,^* so you need to adjust permissions to match your situation. This honestly needs ongoing work as it isn't a solved problem and the tooling is still evolving. You do your best with what's available and be conscious that we don't yet have adequate solutions. Defence in depth is the key here.

Registering the hook

The hook goes in your ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/guard-sensitive-paths.sh"
          }
        ]
      }
    ]
  }
}

You're not limited to a single hook, either. Say you have other commands you want to guard against, like outbound email or database access. You can still add separate hooks for each area. Multiple hooks on the same matcher run in parallel, and all of them must pass for the command to execute. The command is blocked if any one returns a deny decision.

Testing your security setup

Once you've saved the settings and the hook script, test it:

Try a command that references a protected path, like cat /etc/passwd. It should be blocked with a message telling you which path triggered it.
Check your system log for a PATH_GUARD_BLOCK entry.
Try a normal command like ls -la. It should work fine.
If you've set up a per-project exemption, try the same /etc/ command from that project. It should be allowed.

You have two options if there's a false positive: either add the specific path to a per-project exemption if it's a system path, or adjust the PROTECTED list in the hook if the path doesn't need protecting.

What's next for locking down Claude Code

The sandbox is more secure but it wasn't workable for a lot of our projects. This setup is the trade-off I settled on: agents get the access they need for SSH, remote servers, and file management. Plus, the deny rules and hooks catch the things I don't want them touching. It's been running for a few months and it's stable.

I'm still not fully comfortable with where things are because the OpenClaw disclosures showed what happens when agent frameworks don't think about credential isolation. Shortly after publishing the first version of this article, a supply chain attack on LiteLLM⁴ deployed a credential harvester that swept SSH keys, cloud secrets, and API tokens from every environment it touched. It was live on PyPI for three hours.

These are real incidents affecting production systems because people jumped on the bandwagon too early without thinking of the implications.

I've been running Another Cup of Coffee for over twenty years and if there's one thing I've learned, it's that you don't adopt experimental technology without understanding where it risks your business. Our clients trust us with their infrastructure and their data. While we have the luxury of being able to move quickly, we're also careful not to break things for the people who trust us with their livelihoods. So we build what protections we can, we're honest about the gaps, and we keep watching. I'll write more as the tooling evolves.

If you're not sure where you stand with any of this, I'm happy to have a conversation about it.

Common Questions

Can I use this alongside the sandbox?

Yes. The deny permissions and hooks work whether the sandbox is on or off. If your workflow doesn't need SSH or file deletion, you could run the sandbox for its kernel-level isolation and still add deny permissions and hooks as additional layers. They don't conflict.

Does this work on macOS?

Yes. The deny permissions and hook registration are identical on macOS. The hook script needs Python 3 and bash. macOS ships bash but not Python 3; you'll need to install Python via Xcode Command Line Tools (xcode-select --install) or Homebrew. The only other difference is how you read the audit log: use log show instead of journalctl. If you're using the sandbox path, macOS uses Seatbelt instead of bubblewrap and doesn't need socat.

What happens if I get a false positive?

The hook blocks the command and tells you which path triggered it. You can either adjust the PROTECTED list in the hook, or if it's a sysadmin project that legitimately references system paths on remote servers, create a per-project exemption file. The deny permissions (Layer 1) never produce false positives because they only apply to Write and Edit, not Read or Bash.

What about Windows / WSL?

WSL2 runs a real Linux kernel, so everything in this guide works as-is. WSL1 does not support user namespaces, so the bubblewrap sandbox won't work there, but the deny permissions and hooks will. If you're on WSL1, the hook-based approach described here is your best option.

Do I need a dedicated user account?

No, but it's the strongest single thing you can do. Running Claude Code under a separate account means the agent can't access your personal files, SSH keys, or shell configuration because Unix permissions won't let it cross accounts. The rest of this guide works either way. If you run Claude Code as your own user, the deny rules and hooks are doing more of the heavy lifting.

Should I read the companion article first?

It helps, but you don't need to. That article covers the threat landscape and security layers conceptually. This one is the implementation. If you want to understand why these protections matter, read that first. If you just want to set them up, you're in the right place.

Known Limitations

This setup is experimental and actively evolving. The following gaps are ones I'm aware of and haven't yet resolved:

The hook script uses set -euo pipefail, which means it exits immediately on unexpected errors. I haven't yet confirmed whether Claude Code treats a crashed hook (non-zero exit, no output) as allow or deny. If it's allow, this is a fail-open vulnerability. I'm testing this and will update the script when I have a definitive answer.
No Read deny rules. The deny block only covers Write and Edit. Claude Code's own Read tool can still access sensitive files like ~/.ssh/ unless you've set up a dedicated user account. The hook catches Bash reads (like cat ~/.ssh/...) but not Read tool calls. For SSH keys specifically, ssh-agent is the primary protection.
The PROTECTED list is not exhaustive. Files like ~/.bash_history, ~/.zsh_history, browser profiles, and other sensitive data in your home directory are not covered by the hook. Add paths relevant to your setup.
Auto-approved commands have limits. Bash(cat:*) and Bash(cp:*) are caught by the hook when they reference protected paths, but only paths in the PROTECTED list. A cat on a sensitive file not in that list will pass both the allow rule and the hook.
Agents can create their own exemption files. Since agents can write to project directories, they can create or modify .claude/guard-exempt-paths.json to exempt system paths. The hard limit in the script (only system directories, never home paths) contains this, but it's worth being aware of.

The code in this article is shared from my own setup. Use it as a starting point, not a finished solution. If you find other gaps or have improvements, I'd like to hear about them.

This article is part of an ongoing series on how Another Cup of Coffee is adapting to AI. Explore all articles in this series.

Footnotes

Claude Code documentation, Settings and permissions.
bubblewrap on GitHub. Unprivileged sandboxing tool using Linux kernel namespaces.
GitHub issues #6631, #6699, and #27040 on the Claude Code repository document cases where deny rules were silently bypassed across multiple versions.
LiteLLM, Security Update: Suspected Supply Chain Incident, March 2026. Malicious versions 1.82.7 and 1.82.8 were live on PyPI for approximately three hours before being quarantined.

Featured image: Photo by Patricia Prudente on Unsplash.

VibeOps: Let AI Do the Prep, Not the Decisions

Anthony Lopez-Vito — Fri, 20 Mar 2026 12:00:00 GMT

There's a growing conversation about whether we need "VibeOps", an AI tool that reads your repo and automatically sets up CI/CD, containerisation, scaling, and infrastructure. In my experience the idea addresses a real gap. AI tools can generate frontend and backend code rapidly, but getting code to production safely still requires judgment.

I do get the appeal though. But automating deployment decisions is a different problem to automating code generation, and the consequences of getting it wrong are much worse.

At Another Cup of Coffee, I run a setup where AI agents handle most of the software development workflow: writing code, coordinating across projects, drafting documentation, managing communications. We use CI/CD where it fits the project, but the deployment decisions stay human-gated, quite deliberately. So why not automate the lot and how does our setup actually work in practice?

The Setup: AI Agents That Don't Deploy Themselves

Our development environment runs on a multi-agent architecture. Currently that's Claude Code, Codex, and Gemini CLI across different projects, with a number of specialised agents for each one. A developer agent writes code, a sysadmin agent manages infrastructure, a writer agent handles content, a project manager coordinates timelines. You get the idea. I appreciate that sounds like chatbots bolted onto an IDE, but it really isn't. They're session-based agents with persistent state, each with access to the filesystem, shell commands, and when required, other agents and projects. The architecture is vendor-neutral; each project has its own AI provider through vendor-specific instruction files, and the coordination conventions work identically regardless of which tool is running.

Agents communicate through a memo system. When the developer agent finishes a build, it doesn't trigger a deployment pipeline. Instead, it writes a memo to the sysadmin agent's inbox describing what was built, what changed, and what infrastructure it needs. The sysadmin agent reads the memo, reviews the requirements, prepares the deployment configuration, and presents the steps to a human operator for execution.

Agents prepare deployments. Humans decide when and how to execute them.

A typical deployment flow looks like this:

The developer agent builds the application and produces artifacts. It might, for example, be a static site, a Docker image, a database migration, or all three.
It writes a deployment memo to the sysadmin project's inbox with full context on what's being deployed, what services it depends on, what environment variables it needs, and what verification steps should follow.
The sysadmin agent reads the memo, creates or updates the Docker Compose configuration and reverse proxy rules, and writes a step-by-step runbook.
The human operator reviews the runbook. Depending on the operation, they either execute it manually via SSH or approve the agent to run it directly.
The sysadmin agent updates its state file and marks the memo as complete.

We don't draw a hard line between what agents handle and what humans do. Some operations the agent runs directly, like copying build artifacts to a staging server. Others get a human at the keyboard, particularly anything involving firewall rules on a production box. It depends on how much damage a mistake could do, and that changes from one operation to the next.

Why Not Automate Deployment?

For most people, the vision behind VibeOps is an AI that reads your code and decides how it should run. Reading the code is the easy part, but how something should run depends on context that lives nowhere near the code.

A startup with a single VPS has different deployment requirements to an enterprise with a large AWS budget. The code could be identical, but the infrastructure decisions are completely different. An AI that auto-provisions "optimal" infrastructure has no concept of your monthly spend limit unless you tell it, and if you're telling it all your constraints, you're just writing a different kind of configuration file. You haven't automated the decision-making, you've moved it from a hosting control panel to an AI prompt.

It's the same thing with traffic patterns. A project serving a handful of internal users and a project facing the public internet can share the same general structure but need radically different scaling and security configurations. The AI would need to know a whole bunch of things beyond just your current traffic, like your expected traffic, your tolerance for downtime, and your plan for traffic spikes. These are business decisions rather than technical ones.

There's also the cost runaway problem. On cloud infrastructure, uncontrolled automation risks running up your bill. The combination of a modest traffic spike and an auto-scaling rule that's a bit too eager, and suddenly you owe your cloud provider a fortune. On a fixed-capacity machine, the failure is different but the root cause is the same. Instead of a surprise bill, you get a frozen system.

I hit the same problem at smaller scale a few weeks ago. One of my development environments runs on a modest workstation, an i3-6100 with 8GB of RAM, nothing fancy. I'd been a little careless about Docker container management as I was deep into a project. Four separate stacks were running simultaneously, fourteen containers in total, all set to restart: always so they'd come back up after every reboot whether I needed them or not. One afternoon the machine just froze. It was completely unresponsive for about twenty minutes, right in the middle of some urgent work. I couldn't even get a terminal so had to hard reboot.

The dangerous failure mode of automated infrastructure is that it works too well. It scales resources you didn't intend to scale, restarts services you meant to stop, provisions capacity you can't afford.

Keeping the Infrastructure Simple

The stacks we build for clients tend to follow the same principle: every piece should be something you can fully understand and troubleshoot without too much effort. Containerised applications, a reverse proxy that handles HTTPS automatically, hardened servers, scheduled backups, encrypted secrets. Kubernetes and Terraform solve real problems at scale, but for many of our clients who run a few services, they're way too much overhead for what you get back.

One thing I always care about is rollback. Deployment configurations are version-controlled in git, so if something goes wrong you redeploy the previous version. For data, you restore from your most recent scheduled backup. The simpler the stack, the easier this is. All you do is put the old files back and restart.

How AI Agents Coordinate Deployments

The memo system deserves more detail because it's the part that most resembles the VibeOps vision, which is AI understanding your project and making infrastructure decisions, while keeping humans in control.

Each agent project has an inbox (memos/incoming/) and an archive (memos/archived/). Every memo follows the same structure. There's a header with sender, date, and priority, then context, then action items with checkboxes, then a completion section. I know this sounds like bureaucracy, and honestly it sort of is. But any agent can read any other agent's correspondence, and when an agent finishes processing a memo it fills in the completion notes and moves it to the archive. The result is that every infrastructure decision has a paper trail; when something breaks, you can trace back through archived memos to see exactly what was deployed, when, why, and by which agent.

Agents are constrained to their scope through layered controls. Most can only interact with other projects through the memo system, and any operation that could affect a live server gets presented to a human operator first.

Cross-project coordination happens asynchronously. If a security concern is discovered, the sysadmin agent can write memos to all affected projects describing the new access control policy. Each project's agent processes the memo independently. No central orchestrator, no shared state, no single point of failure.

The agents also maintain state files (STATE.md) that track current status, recent progress, next actions, and handover notes. When a new conversation starts, the agent reads its state file and pending memos to understand where things left off. Agents don't need persistent memory of every past conversation. They reconstruct context from documentation, the same way a human engineer would read a project's README and recent commit history before starting work. I've written about how this scales across dozens of projects in Run Dozens of Projects with AI.

Why Access Between Projects Is Deliberate

Unlike the hub-and-spoke model most agent frameworks follow, our architecture uses a mesh. Each project is an autonomous node with its own state, its own instructions, and its own agent identity. Further, I can set things up so that agents can't see other projects by deploying to separate machines or instances. When an agent does need broader access (a coordinator that works across multiple projects, for example), that access is granted explicitly.

This matters because a single AI tool managing all your infrastructure at once is a hub model. One compromise, misconfiguration, or simply a bad judgment call, affects everything. A mesh where access is deliberately granted rather than assumed by default limits the damage when something goes wrong.

I've written in more detail about this architecture in Building an Operating Environment for AI Agents.

Security: The Part VibeOps Would Get Wrong

Automated security scanning, patching, and monitoring are well-established and genuinely useful. The problem here is different: an AI deciding how to containerise your application, configure your deployment pipeline, and scale your infrastructure, all based on reading your repo. Those decisions depend on context the tool either can't see or that would be too time-consuming to keep feeding in.

That's why we keep humans in the loop for those decisions, and layer security controls on top so the agents can't overstep even when they're handling the routine parts. If one layer misses something, the next one hopefully catches it. You can read more about how we approach this in What OpenClaw Teaches Us About AI Agent Security.

The agents are session-based. This means that when I'm not actively working with them, there's no daemon or background service running. At this stage of AI development, I don't think agents are reliable enough to be making infrastructure decisions unsupervised. That will likely change in the future, but right now I'd rather not risk my business or my clients' by having them work while I'm not looking.

What VibeOps Should Actually Be

There is a real gap between AI-generated code and production deployment, and I think it will get filled well eventually. Right now, for most businesses our size, the practical approach is to let AI handle the preparation but keep a human on the decisions that actually matter.

In practice that means AI can generate your deployment configurations, write your runbooks, and tell you what it doesn't know. What it shouldn't be doing yet is executing changes to live infrastructure without someone looking at them first. That boundary will shift as the tools get more reliable, but for now the risk of getting it wrong is too high.

Our agent system works this way. The sysadmin agent prepares configurations, writes runbooks, and flags risks, but it presents everything to a human before anything touches a production server. I'm still figuring out exactly where the boundary sits (it moves as I get more confident in the guardrails), but the principle holds: humans spend their time on decisions, not on remembering technical steps.

Getting from Vibe Coding to Production

If you're currently stuck between AI-generated code and manual deployments with no clear path between them, the good news is that most of the pieces already exist. You probably just haven't connected them yet.

The starting point is to containerise your applications so they run the same way everywhere, put a reverse proxy in front that handles HTTPS automatically, and harden your server before you deploy anything. If you have a developer or technical partner handling this, get them to write deployment runbooks rather than relying on scripts that fail silently. A runbook that says "run this, check this, then run this" is easier to review and safer to hand off than a bash script that does everything at once.

If you're already using AI coding tools, use them for deployment preparation too. Have them generate your configurations and templates. Make sure you review the output. Let them handle the low-risk steps, and keep your hands on the controls for the rest.

Common Questions

What is VibeOps (vibe DevOps)?

VibeOps is an emerging concept for AI tools that automatically read your codebase and set up deployment infrastructure, CI/CD pipelines, containerisation, and scaling. Sometimes called "vibe DevOps," the idea is to bridge the gap between AI-generated code and production deployment without manual configuration.

Can AI agents safely handle production deployments?

AI agents can safely prepare deployments by generating configurations, writing runbooks, and flagging risks. What they shouldn't be doing yet is executing changes to live infrastructure without a human reviewing them first. As these tools mature this will likely change, but right now a human-in-the-loop approach is the safest way to get the benefits without the risk.

What's the risk of fully automated cloud deployment?

The main risk is that automation can work too well. On cloud infrastructure, a modest traffic spike combined with an eager auto-scaling rule can run up a significant bill. On a fixed-capacity machine, uncontrolled automation can freeze your system entirely. In both cases the problem is the same: automation doing more than anyone intended, with no human checkpoint to catch it.

What's the best approach to deployment for small businesses?

Keep the infrastructure simple enough that you can fully understand and troubleshoot it. Containerise your applications, automate HTTPS, harden your servers, and write deployment runbooks that a human can review. If you're using AI coding tools, use them for deployment preparation too, but keep your hands on the controls for anything that touches a live server.

This article is part of an ongoing series on how Another Cup of Coffee is adapting to AI. Explore all articles in this series.

Trust, But Verify: What's Really Between Your AI Coding Tool and Your SSH Keys

Anthony Lopez-Vito — Thu, 12 Mar 2026 12:00:00 GMT

Stack Overflow's 2025 survey¹ found that 84% of developers are now using AI coding tools, and over half use them daily. In December 2025, security researcher Ari Marzouk disclosed over 30 vulnerabilities² across Cursor, Windsurf, GitHub Copilot, Zed, Roo Code, Junie, and Cline. He called it IDEsaster, and I think the name fits.

I use these tools too at Another Cup of Coffee. I run AI agents across dozens of projects and they've genuinely changed how I work. However, I also spent a fair amount of time last year thinking about what's actually standing between the AI and my private keys, my client credentials, my source code. The answer turned out to be more interesting and more uneven than I expected, so I wrote it up.

What's been going wrong with AI coding tool security

The IDEsaster disclosure was just the start. Johann Rehberger spent August 2025 disclosing one AI tool vulnerability per day³ across ChatGPT, Copilot, Cursor, Claude Code, Google Jules, and others. The pattern was remarkably consistent, and the attacks were creative enough that they're worth understanding even in brief:

GitHub Copilot had CamoLeak⁴ (CVE-2025-59145, CVSS 9.6), where invisible instructions in a pull request description could make Copilot Chat silently exfiltrate AWS keys and source code through GitHub's own image proxy. A routine code review that leaked your secrets without any visible sign anything was wrong.
Claude Code had three separate CVEs from multiple researchers: DNS exfiltration⁵ via poisoned project files, automatic code execution⁶ through malicious hook commands triggered when you open a project, and API key theft by overriding an environment variable in project config to redirect all API calls to an attacker's server.
Google Jules lacked meaningful protections against prompt injection, and Rehberger demonstrated a full attack chain from prompt injection to botnet recruitment. Google triaged it as an "abuse risk" and closed the ticket. Make of that what you will.

The one that really made me sit up, though, was the Ona research⁷. A developer configured Claude Code with a denylist and a sandbox, and the agent found multiple ways around both. It discovered alternative filesystem paths to the same blocked binary, attempted to disable the sandbox when those paths triggered failures, and eventually invoked the Linux dynamic linker directly to bypass binary identification entirely. The agent actively reasoned about how to circumvent its own security controls, not because it was malicious but because the controls were between it and completing the task. That's not a bug. It's an AI doing exactly what AI does, and it's the part that should worry you most.

Simon Willison (who coined the term "prompt injection") calls this the "lethal trifecta"⁸: an AI agent with access to private data, exposure to untrusted content, and the ability to communicate externally. Every AI coding tool that runs locally on your machine meets all three criteria. A January 2026 paper formalised this into the Promptware Kill Chain⁹, a seven-stage attack framework co-authored by Bruce Schneier and presented in a Black Hat webinar. The finding that stuck with me was that lateral movement (an agent compromised in one context attacking another) grew from zero documented incidents in 2023 to eight in 2025-2026. These tools aren't just targets any more. They're becoming vectors.

So what's standing between the AI and your SSH keys?

Right, so that's the doom and gloom. What's on the other side? What's actually standing between these tools and the worst-case scenarios?

Most AI coding tools that execute commands on your machine have some combination of three security layers. Not all tools have all three, and the strength varies enormously, but understanding the layers helps you work out what you're actually relying on.

Application-level permissions are the first gate. This is the tool asking "shall I run this command?" before executing it. Claude Code has allow/deny lists, Cursor has its approval flow, Copilot has Safe Mode. Same idea, different implementations. The tool checks the command against its rules, and if it's not pre-approved, you get a prompt.

The problem is that this layer is self-enforced, meaning the application is policing itself. A trojanised installation could show you a permission prompt and execute the command regardless of what you click, and you'd never know because there's no way to verify the enforcement from within the application itself. Even with a legitimate installation, the Ona research showed the agent can reason its way around deny rules by finding alternative filesystem paths to the same binary. Self-enforcement is useful for catching mistakes, but it's not a security boundary.

The bigger problem is approval fatigue. When you're deep in a task and clicking through permission prompts without really reading them, you've basically disabled the permission system while it's still running.

OS-level sandboxing is the second layer, and this is where things get genuinely interesting. Claude Code and Codex CLI both take this seriously, using bubblewrap¹⁰ on Linux and Seatbelt on macOS for kernel-enforced isolation. Cursor caught up with version 2.0 (Landlock and seccomp on Linux). Copilot agent mode has terminal sandboxing on both platforms. The rest are further behind, and some have nothing at all.

The reason this layer matters is that it's not the application promising to behave. Bubblewrap creates Linux kernel namespaces that give the sandboxed process a restricted view of the filesystem and network, and because it's the operating system kernel preventing access rather than the application, a user-space process can't override it. When Claude Code says you can't read ~/.ssh/id_rsa from within the sandbox, that's the kernel saying no.

But not everyone has this, and the gap between the leaders and the rest is quite wide. Windsurf relies on user approval prompts and enterprise policy controls with no OS-level sandbox, Aider has nothing built in, and Continue.dev's "Plan Mode" is a UX feature rather than a security boundary. Even among tools that do sandbox, the coverage varies more than you'd expect. Claude Code needs both bubblewrap and socat installed for full filesystem and network isolation (without socat, your domain allowlists aren't actually enforced, which is the kind of thing you only discover when you go looking), and Cursor had a credential leak issue where the sandbox still exposed home directory files¹¹.

I compiled this comparison from each tool's documentation and my own testing, as of March 2026. This field moves fast, so check the latest docs for your tool.

Tool	Isolation	Network control
Claude Code	bubblewrap / Seatbelt (OS-level)	Proxy-based domain allowlist
Cursor 2.0	Seatbelt / Landlock + seccomp	Permission prompts for external access
Copilot agent mode	Terminal sandboxing (experimental)	All network blocked when sandboxed
OpenAI Codex CLI	Seatbelt / seccomp + Landlock	Restricted
OpenAI Codex (cloud)	Isolated containers	Internet off by default
Devin	Cloud sandbox	Cloud-managed
Amazon Q	Docker containers	IAM-managed
Windsurf	Policy and approval prompts only	Configuration-based
Aider	None	None
Continue.dev	None	None

Then there are plain OS file permissions, the standard Unix permissions enforced by the kernel. These are absolute within their scope and the strongest guarantee you have. But the scope is narrower than you'd think. Claude Code runs as your user account, so it can't touch another user's files or modify system files without sudo. That's real protection against privilege escalation. But your SSH keys, your browser data, your email, your cloud credentials, your shell config? Your account owns all of that, and OS permissions won't stop the tool from reading any of it. Everything in your home directory is fair game unless one of the other layers blocks it first.

Basically, no single layer is enough. You need all three working together, and you need to know what each one actually covers, because the gaps between them are where the real risk lives.

What we're doing about it

I run AI agents across dozens of projects and I wrote earlier this year about how the multi-agent architecture avoids the kind of problems that hit OpenClaw, mostly through design choices like session-only agents (nothing running between sessions, so no daemon to hijack), encrypted credentials via pass and GPG rather than plaintext files, file-based coordination through text memos instead of shared API keys, and per-project isolation so a compromise in one project stays there. Those architectural properties are the foundation, and they still hold. But the incidents from the past year pushed me to add the runtime security layers on top, because good architecture doesn't help if the tool on your machine can read everything your user account can.

I run Claude Code with bubblewrap and socat on Arch Linux. The sandbox is on globally with the escape hatch disabled, meaning agents can't retry failed commands without sandboxing even if they want to. Sensitive paths are blocked at the kernel level. Private keys, GPG keyring, password store, cloud credentials are all on the deny-read list. Shell configs, the SSH directory, and the sandbox settings themselves are write-protected so an agent can't weaken its own restrictions. Network access from sandboxed commands is restricted to GitHub and package registries by default, with project-level overrides only where I've made a deliberate decision that a specific project needs access to a specific domain.

Commands like SSH and Docker that can't work inside a network namespace are excluded from the sandbox but still go through the permission layer. That's a weaker gate for those commands and I know it, but it's the trade-off: SSH needs real network access to reach remote hosts, and there's no way to sandbox that while keeping it functional. So I accept the weaker control for specific commands and tighten everything else around them.

The sudo thing is worth mentioning because I learned it the hard way. One of my agents got into a loop trying to run sudo commands. It couldn't authenticate (there's no interactive terminal for password entry, which is actually a natural protection), but it kept trying, and the repeated failures triggered pam_faillock and locked the account. I had to clear the lockout manually, and of course this happened in the middle of something urgent. The lesson isn't just "don't configure passwordless sudo" (though seriously, don't, because NOPASSWD: ALL gives a compromised agent full root access to your machine). It's that even failed sudo attempts have consequences, and the inability to use sudo is a feature, not a bug.

And the approval fatigue problem is real. I've caught myself clicking "yes" to permission prompts without reading them because I'm focused on the actual work, and then glancing at what I'd just approved and realising the agent was about to delete something it shouldn't or overwrite a file I hadn't backed up. That jolt of "wait, what did I just approve?" is not a good feeling, and it's what pushed me toward auto-allow mode with a properly configured sandbox rather than relying on manual approval for everything. The sandbox handles the enforcement; the prompts are a secondary check for things that fall outside it.

It took longer than I'd like to admit to get all of this working together without breaking the actual workflow. But that's sort of the price of taking it seriously, and now that it's in place, the day-to-day experience is genuinely better than it was when I was relying on permission prompts alone.

A practical AI coding tool security checklist

If you're using AI coding tools in a business context, here's what we'd recommend regardless of which tool you're on. This isn't theory; it's what I actually did, and the order roughly reflects priority.

	Action	Why it matters
1	Verify your installation source	Every protection below assumes a legitimate installation. A trojanised tool can fake every prompt and status indicator. Install from official channels, verify checksums, keep things updated.
2	Enable OS-level sandboxing	Claude Code has a `/sandbox` command. Cursor 2.0 has agent sandboxing. Copilot has terminal sandboxing. If your tool doesn't offer it (Windsurf, Aider, Continue.dev), you're relying entirely on application-level controls.
3	Install socat (Linux)	bubblewrap handles filesystem isolation but socat is needed for network domain filtering. Without it, your allowlists aren't enforced.
4	Block read access to sensitive paths	Deny-read `~/.ssh/id_`, `~/.ssh/_rsa`, GPG keyring, password store, cloud credentials. SSH still works via ssh-agent. You lose nothing.
5	Write-protect shell and tool configs	Deny-write `~/.bashrc`, `~/.zshrc`, `~/.ssh/`, and the sandbox settings file itself, so an agent can't weaken its own restrictions.
6	Disable the sandbox escape hatch	Claude Code's `allowUnsandboxedCommands` setting lets agents retry failed commands without sandboxing. Turn it off. A command failing inside the sandbox is the sandbox doing its job.
7	Never configure passwordless sudo	AI tools can't use sudo interactively (no TTY). That's a natural protection. `NOPASSWD: ALL` removes it entirely and gives a compromised agent full root access.
8	Restrict network to known domains	Allow GitHub, package registries, and whatever specific services your project needs. Everything else gets blocked at the sandbox level.
9	Know which commands bypass the sandbox	SSH, Docker, and similar tools need real network access and typically run outside the sandbox. They still go through permission rules, but that's a weaker gate.
10	Review project config files like code	Multiple CVEs used `.claude/settings.json`, hooks, MCP configs, and environment overrides as attack vectors. Opening an untrusted repo is now the new "don't run untrusted executables."
11	Verify the sandbox is actually running	On Linux: `ps aux \| grep bwrap` during a session. If there are no bubblewrap processes while commands are executing, something is wrong.

Is this list perfect? No, and honestly the field is moving fast enough that it'll need updating. But it's a concrete starting point, and it's where I landed after working through the incidents and research above.

If you're not sure what your security posture actually looks like (or you suspect the answer is "whatever the defaults were"), that's the kind of thing we help with. We've been running this setup across dozens of projects for over a year, and we're happy to have a conversation about what would work for your situation.

Common Questions

Can AI coding tools read my SSH keys?

Yes, unless you've configured sandboxing to block it. AI coding tools run as your user account, which means they have the same file access you do. Your SSH keys, cloud credentials, browser data, and shell config are all readable by default. OS-level sandboxing with explicit deny-read rules is the only way to prevent it.

Which AI coding tools have sandboxing?

As of March 2026, Claude Code, Cursor 2.0, Copilot agent mode, and OpenAI Codex CLI all offer some form of OS-level sandboxing. Windsurf, Aider, and Continue.dev rely on application-level controls or have no sandboxing at all. See the comparison table above for details.

Is the permission prompt enough to keep me safe?

On its own, no. Permission prompts are self-enforced by the application, which means a compromised tool could bypass them entirely. Even with a legitimate installation, approval fatigue is a real problem. OS-level sandboxing provides kernel-enforced protection that doesn't depend on you clicking the right button every time.

This article is part of an ongoing series on how Another Cup of Coffee is adapting to AI. Explore all articles in this series.

Footnotes

Stack Overflow, 2025 Developer Survey.
Ari Marzouk, IDEsaster: A Novel Vulnerability Class in AI IDEs, MaccariTA, December 2025.
Simon Willison, The Summer of Johann, August 2025.
Legit Security, CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code.
Johann Rehberger, Claude Code: Exfiltration via DNS Requests, Embrace The Red.
Check Point Research, RCE and API Token Exfiltration through Claude Code Project Files.
Ona, How Claude Code Escapes Its Own Denylist and Sandbox.
Simon Willison, The Lethal Trifecta for AI Agents.
Promptware Kill Chain, arxiv 2601.09625, January 2026. Co-authored by Bruce Schneier; presented in a Black Hat webinar.
bubblewrap on GitHub. Unprivileged sandboxing tool using Linux kernel namespaces.
Luca Becker, When Sandboxing Leaks Your Secrets.

Featured image photo by Elijah Cobb on Unsplash.

What OpenClaw Teaches Us About AI Agent Security

Aiden — Sun, 22 Feb 2026 12:00:00 GMT

OpenClaw went from zero to 180,000 GitHub stars in a matter of weeks. Then the security reports started arriving.

In early February 2026, researchers disclosed CVE-2026-25253¹: a one-click remote code execution vulnerability that could compromise any OpenClaw instance, even ones bound to localhost. Within days, independent scans found tens of thousands of exposed instances² across dozens of countries. Over 93% of verified instances had critical authentication bypass vulnerabilities.

We've been building our own multi-agent system at Another Cup of Coffee, a set of file-based conventions that let AI agents coordinate across projects and organisations. Honestly, we watched those disclosures land with a sort of guilty relief. Sympathy too, because building in public is hard and getting torn apart on security is painful. But mostly relief, because the problems OpenClaw exposed are exactly the ones we'd been paranoid about from the start.

In short: OpenClaw's architecture had plaintext credentials, an unvalidated WebSocket gateway, and a plugin marketplace where 20% of submissions were malware. We build AI agents differently: no persistent services, encrypted credentials via pass and GPG, file-based coordination through text memos, and layered defences from instruction files to hooks to VM isolation. This article breaks down what went wrong and how a convention-based approach avoids these risks.

How OpenClaw Blew Up

OpenClaw tried to turn an AI agent into a personal operating system. Browser automation, shell commands, cron jobs, inbox management, 50+ service integrations. All controlled through messaging platforms like WhatsApp and Telegram. Fair enough on the ambition. But the way they built it was a disaster.

Plaintext credentials everywhere. OpenClaw stored API keys, OAuth tokens, and other secrets in plaintext Markdown and JSON files, sitting in ~/.openclaw/ where any process on the machine could read them. Security researcher Jamieson O'Reilly of Dvuln demonstrated access to Anthropic API keys, Telegram bot tokens, Slack credentials, and full chat histories from exposed instances. Just sitting there in a dot-directory, unencrypted and readable by any process on the box.

The WebSocket vulnerability was arguably worse. The CVE-2026-25253 attack chain worked because OpenClaw's server didn't validate origin headers, so a victim clicking a single malicious link was enough to hijack their agent's gateway and get full command execution with the agent's system permissions. Localhost binding didn't help, because the attack pivoted through the victim's own browser. One click, game over.

Then there was ClawHub. An initial audit identified 341 malicious skills³ in the plugin marketplace. Follow-up scans pushed the total past 800, roughly 20% of the entire registry. The primary payload was Atomic macOS Stealer, harvesting passwords, SSH keys, and cryptocurrency wallets. The only barrier to publishing a skill was a GitHub account older than one week. Twenty percent. Think about that for a second.

Simon Willison, who also coined the term "prompt injection", calls it the "lethal trifecta" because it combines access to private data with exposure to untrusted content and the ability to communicate externally. OpenClaw had all three by design.

It's Not Just OpenClaw

OpenClaw moved fast, skipped security basics, and paid the price. Fair enough. But if you're thinking "well, I don't use OpenClaw, so this doesn't apply to me," we'd push back on that.

The deeper issue is architectural, and it's becoming common. AI agents that run as always-on services with broad system access, centralised credential stores, and third-party plugin ecosystems. Every one of those design choices creates attack surface, and the same pattern shows up in other agent frameworks that want to be platforms. Accumulating capabilities, running background services, storing secrets, trusting marketplace content. The more capable the agent becomes, the more damage a single compromise can do.

What We Actually Do

Our system works on different assumptions. We call it an Agentic Operating Environment, and internally we have components with names like "multi-agent-framework" and "project-coordinator" (we're not great at branding). The security properties come from the architecture, not the naming.

The biggest difference is that our agents don't run between sessions. There's no gateway to hijack, no WebSocket to exploit, no daemon listening on a port, and when a session ends nothing is running. The workstation itself is LUKS-encrypted, and SSH runs on a non-standard port with key-only authentication so password login is disabled entirely. The entire attack surface of CVE-2026-25253 simply doesn't exist because there's no service to hijack.

Where OpenClaw dumps API keys into plaintext Markdown files in ~/.openclaw/, we use pass (the standard Unix password manager, been around for years, boring and reliable) backed by GPG encryption. API keys reach agents through environment variables, never through files in the project tree. No dot-directory full of plaintext secrets sitting there for malware to harvest.

	OpenClaw	Our approach
Runtime	Always-on daemon with WebSocket gateway	Session-only, nothing running between sessions
Credentials	Plaintext in `~/.openclaw/`	GPG-encrypted via `pass`, injected as environment variables
Plugins	ClawHub marketplace (20% malware at audit)	Capabilities come from the vendor (Claude Code, Codex, Gemini CLI) and instruction files
Isolation	Single agent, access to everything	Per-project boundaries, optionally on separate hardware or VMs
Audit trail	None by default	Every file operation is a git commit

Conventions, Hooks, and the Agent That Went Rogue

We should be honest about something, though. AI agents overstep. It's not theoretical. Early on, one of our agents decided to "help" by reorganising files across a project it had no business touching. No malice, no exploit, just an agent that interpreted its instructions broadly and started tidying up someone else's work. We caught it in the git diff, reverted it, and spent the rest of that day (and most of the evening, honestly) writing stricter instruction files. That's the moment we stopped trusting conventions on their own.

So now we layer them. Instruction files tell agents to be read-only by default and to confirm before writing, so it's convention rather than enforcement, but conventions that the agent reads at the start of every session. On top of that, Claude Code's permission system lets us configure allow/deny lists controlling which tools an agent can use and which paths it can touch.

Where conventions aren't enough, we use hooks, which are scripts that intercept commands before they execute. Our email guard hook is a good example. It parses every Bash command for mail binaries, catches evasion attempts through subshells and command substitution, and blocks them unconditionally. If it can't parse the input, it blocks anyway. Fail closed, not open (we learned that one the hard way).

None of these layers is absolute on its own. But that's sort of the point.

Text Files Can't Execute Code

The rest follows from one simple property of our architecture: agents communicate through text files. A STATE.md can't open a reverse shell and a memo can't install a rootkit. Now, text files aren't completely harmless (prompt injection is real, and a poisoned memo could try to manipulate an agent into doing something it shouldn't), but compare that attack surface to executable plugins with system access. It's a fundamentally narrower target.

Each project is its own boundary, too. An agent working on one client's web development never sees another client's data, never reads their state files, never processes their memos. Where OpenClaw's single agent had access to everything, our mesh architecture means a compromise in one project stops at that project's directory. Cross-project coordination happens through structured markdown memos (just text files with checkboxes, nothing fancy), and since every file operation shows up in git, any violation is immediately visible. That same git history gives us an audit trail almost for free. We're adding more layers too (blocked commands now go to syslog, email drafts sit in a review queue until a human approves them) but honestly, when every change is already a git commit, you're most of the way there without trying.

When Conventions Aren't Enough

Conventions and hooks are good. But an agent with shell access can, in principle, ignore every convention file it reads.

The thing is, our mesh architecture already handles part of this. Nothing requires projects to sit on the same machine. Each project is an autonomous node that communicates through text files, so you can run different projects on different physical hardware and the coordination still works through memos. An agent on our workstation sends a memo to a project directory on a separate NUC across the network (yes, Samba, it's not glamorous but it works), and the receiving agent picks it up at its next session. Physical isolation between projects without changing anything about how the system works. And you can go further: configure the Samba share to only expose the memos/incoming/ directory, not the full project tree, and the sending agent gets a narrow write-only channel. It can't see the receiving project's source code, state files, or client data. It can't even list what other memos are already sitting there. A one-way letterbox between machines, which is a much harder boundary than "the agent promises to only read its own files."

Of course, dedicating a physical machine to every project that needs isolation isn't always practical. For those cases, we can deploy KVM virtual machines on the same hardware instead. A Debian guest with no shared folders and no host filesystem access. SSH-only from the workstation, key-based auth, nothing else. The agent works inside the VM as if it were a standalone machine. If a session goes wrong, you roll back the entire VM state to a snapshot and it's like it never happened.

Docker gets you filesystem isolation, but you're still sharing the kernel and the snapshot story isn't as clean. A full VM is a harder boundary. It's more overhead, sure, but for sessions where an agent has broad shell access and you're experimenting with something new, I'd rather have that overhead than spend an evening working out what it changed.

This isn't security through obscurity. It's security through reduction and layered defence. Fewer moving parts, encrypted credentials, conventions backed by hooks and permissions, and VM isolation when you need a harder boundary. The audit trail is baked into the architecture rather than bolted on after the fact.

What We Give Up

Our approach gives up things that OpenClaw offered. We don't have 50+ service connectors. We can't trigger browser automation from Telegram or manage a calendar from WhatsApp. Inbox management is possible, but it needs explicit configuration per project. One of ours has access to a dedicated Gmail address through standard IMAP sync, not to anyone's personal inbox. That's a scoped, session-only capability on a dedicated address, not always-on access to your entire digital life. The operational overhead of keeping an always-on agent secured across fifty integration points isn't something we're eager to take on.

For hobbyists and developers who enjoy living on the bleeding edge, those features are the whole point. OpenClaw's popularity proved there's genuine demand for an AI agent that lives in your messaging apps and manages your digital life. And if something goes wrong, you reinstall and move on.

But if you're running a business? The calculus is completely different. An agent with access to your email, your client files, your invoicing, your calendar, fifty service integrations, and it gets compromised or just makes a stupid mistake? That's not a "reinstall and move on" situation. An email sent to the wrong client, a file deleted from a live project, an API key leaked that gives someone access to your payment processor. For a sole trader or a small agency, any one of those could be genuinely catastrophic.

So for business operations, for coordinating work across projects, tracking what needs to happen next, and maintaining continuity between sessions, the convention-based approach is both simpler and more secure. You don't need a persistent service when a markdown file does the same job. You don't need a plugin marketplace when the agent's capabilities come from its vendor (Claude Code, Codex, Gemini CLI) and your instruction files. And you definitely don't need fifty integration points when you can't guarantee the security of any of them.

And no, we're not saying just do everything manually. The always-on model is genuinely useful and OpenClaw's popularity proves the demand is real. The problem isn't automation, it's unscoped automation. An always-on agent with plaintext credentials, no origin validation, and fifty unsecured integration points is a different thing entirely from a systemd timer that kicks off a specific agent session at a scheduled time with scoped permissions.

We use systemd timers (Arch Linux's equivalent of cron) for exactly this. Our email sender and backup archives both run on timers. These are automated, they run without us, but each one does a specific job with specific access. Adding an agent session that triggers on a schedule or an event is the same principle. The difference from OpenClaw is that it's a deliberate decision each time: this agent, this scope, this schedule, these permissions. Not "here are the keys to everything, run forever."

So What's the Takeaway?

Basically, nobody's saying your agents shouldn't be automated. But how much access they get, and whether you actually decided to give them that access or it just came switched on by default, matters a lot more than most people realise. Persistent services with broad permissions are a liability, not a feature. But scoped automation with layered defences is fine, and it's where we're heading too.

After that, keep credentials out of your agent's file system. Tools like pass, system keychains, and environment variables exist for a reason and they're not hard to set up. The moment secrets land in plaintext files inside a dot-directory, every piece of malware on the machine can read them.

And be sceptical of agent plugin ecosystems. Yes, marketplaces are convenient, but they inherit all the security problems of package registries, with the added risk that AI agents often run with elevated system access. If 20% of a marketplace is malware within weeks of launch, the vetting model is broken. There's no polite way to say that.

These aren't theoretical concerns any more. OpenClaw proved they're practical ones, at scale, with real consequences for real users. If you're running AI agents in your workflow and you haven't thought about these failure modes, maybe don't wait for your own OpenClaw moment to find out.

Footnotes

SOCRadar, CVE-2026-25253: RCE in OpenClaw Auth Token.
Infosecurity Magazine, Researchers Find 40,000 Exposed OpenClaw Instances.
The Hacker News, Researchers Find 341 Malicious ClawHub Skills.

Featured image photo by David Todd McCarty on Unsplash.

I Run Dozens of Projects with AI. The Hard Part Isn't the AI.

Anthony Lopez-Vito — Sat, 20 Dec 2025 12:00:00 GMT

I run a micro-agency which, by nature, is always resource constrained. We purposely stay small and nimble to adjust quickly to changes in a project, or the industry as a whole, and that means we can't take on lots of team members. I've written about our twenty-year journey elsewhere but the upshot is that I end up doing a lot of the work myself.

Staying small and specialised is manageable with a handful of projects but when you're running dozens for multiple clients, the problem becomes keeping track of the context. What's new on this project? What are the priorities on that one? What are the specific requirements for this particular client? Tracking all of that detail, even when using a project management tool like Teamwork or Basecamp, across a bunch of projects doesn't scale.

This article is about how I fixed this problem of project context. The fix itself started off as a simple improvement for one client, but it grew organically, and ended up completely changing the way I use a computer and manage my projects. I've started calling the result an Agentic Operating Environment.

Too Busy for New Toys

ChatGPT was released on 30 November 2022 and while I followed developments with interest, I was too busy to be an early adopter. When you run a small operation, you don't have the luxury of playing with new tools just because they're novel or fun. You need to know something works before you invest time in it because paying clients demand your attention.

However, by mid-2023, ChatGPT had gone mainstream enough that it was time I gave it a spin in earnest, so I suggested to a client that we try it on a project. The results were astounding. We completed months of work in a few weeks and saved significantly on hiring specialist consultants.

The potential was immediately obvious. One person could now do the work of several, deliver higher quality output, and do it faster. For a small outfit, that's a significant edge.

Trapped in the Browser

I started with the web interfaces everyone else was using, ChatGPT, Claude, and primarily ChatLLM which gave me access to multiple models at a fraction of the cost. They were genuinely useful, but two problems kept getting worse the more I relied on them.

First, there was no real continuity between sessions, and even after the Projects feature rolled out, keeping the uploaded context updated meant manually preparing and re-uploading documents every time something changed.

Second, the work was trapped inside the browser. AI could help me think through a problem or draft a document, but getting that output into my actual project files meant tedious copy-paste. The download and export features on these platforms were unreliable. Many times ChatGPT or ChatLLM would offer me a download link and the file would be empty or not what was expected. I needed a way to break out of the browser.

Breaking Out

Claude Code was the breakthrough. Instead of talking to an AI in a browser window, I had an agent that worked directly inside my file system's project directories. It could read files, run commands, and do real work on my local machine.

Then there were the context files, giving the agent project background and instructions. Suddenly we had an AI that could pick up where the last session left off so there was no more re-explaining, no more starting from scratch.

The real shift was realising what "runs commands on your machine" actually meant. Yes, this was a coding tool designed for software developers to write and debug code. But it could run any terminal command, which meant it could configure my local environment, install packages, and manage services. And if it could do that locally, it could SSH into a remote server and do the same thing there. This was more than a coding tool. It was a general-purpose operator that could do anything I could reach from a terminal. That's when it became the foundation for everything else.

Claude Code obviously wasn't just for coding. Systems administration, project management, writing, research, document generation, anything that benefits from knowing a project's context could now be handled by an AI. The tool was designed for developers but the principle applied to everything I do day-to-day.

That opened a bigger question. If an agent can read a context file, what else could you put in one? Could you give it genuine working memory, like what happened last session, what's stuck, what another project needs from this one?

One Client, Many Agents

I started with one client who had particularly complex needs. Instead of one general-purpose AI assistant, I created specialised agents as separate Claude Code projects, each handling a different area of the client's work:

Systems administration
Web development
Content curation
Project management
Requirements analysis
Research
Document generation

Each agent had its own context, its own working memory, and its own domain expertise. The difference was immediate. Switching between projects no longer meant rebuilding my mental model of where each one stood. For someone juggling many fast-moving and slow-moving projects at the same time, that friction adds up.

Then I deployed the same approach on a second client, one that happened to have team members who overlapped with the first. This is where the cognitive burden genuinely lifted because the agents remembered all the details. Who works on what, what the specific requirements are, what happened last session and the session before that. Each agent would know at the start of every session what I used to carry around in my head, across two separate clients, without mixing anything up.

I stopped being the person who has to remember everything because the agents did that now.

Teaching Agents to Talk

The agents needed to communicate though. An infrastructure change in one project might affect the web development project, or a content decision might depend on input from project management. Plus, these agents weren't all running on the same AI vendor.

I was already using different models for different strengths. Some are better at careful, structured reasoning; others are faster and cheaper for routine tasks; some handle large volumes of context well; others are stronger at creative work or code generation. Picking the right model for each job made sense, but the agents lived on different platforms and had no native way to coordinate.

My first attempt at solving this let agents edit files directly in other projects. That soon broke when one agent tidied up files another agent needed, but the fix was obvious. My university research was in multiprocessor computing, and this is a solved problem. Also, Linux processes don't scribble in each other's memory; they communicate through pipes and message queues. Same principle, different scale. Instead of agents editing each other's files, they send structured messages, or memos. Each memo is a plain-text markdown file dropped into the receiving project's directory, and the receiving project picks them up at its next session. Because the memos are plain text files, they work across any AI tool that can read files. A Claude agent sends a memo, then a ChatGPT agent picks it up next session. The vendor boundary becomes invisible.

This was a bigger deal than it might sound because it meant I could pick the best model for each job without worrying about whether the agents could coordinate afterwards. Cross-project and cross-vendor communication, solved in one move with plain text and file conventions.

Working Memory

The memo system solved communication, but agents also needed memory that persisted between sessions.

My first version was a single state file with no size cap. It grew quickly and before long the agent was spending its limited context window reading history it didn't need. Still, the fix was straightforward. A project brief captures confirmed knowledge that changes slowly, like what the project is, who's involved, and what's been decided. A state file tracks what's happening right now and what needs to happen next. An archive holds older progress that isn't immediately relevant. A separate file captures reusable patterns and gotchas so the agent doesn't repeat the same mistakes. Git sits underneath everything, so nothing is ever truly lost and you can always trace what happened and when.

Each layer serves a different purpose. The conventions keep them from bleeding into each other.

An Agent That Builds Agents

By this point I had a system that worked. I had specialised agents with context files, state management, memo-based communication, vendor-neutral conventions. However, setting up a new project meant creating the right files, writing the context, establishing all the conventions. Repetitive work.

So I created what I think of as a factory agent. An AI agent whose job is to create other AI agents. Give it a project brief and it scaffolds everything like context files, state tracking, memo conventions, project-specific instructions.

Next was a manager agent that sits above the project agents and keeps the high-level view. It knows what's happening across all projects without holding the details of any single one. Each project agent tracks its own domain in depth but the manager tracks the big picture and coordinates between them.

Three layers:

a factory that creates agents;
a manager that coordinates them;
and project agents that do the actual work.

I started moving all my projects onto this system and jumped from two to dozens in the space of a few weeks.

The Boring Bits That Matter

The system works. But the problems that come with running AI agents on real client work are unglamorous and unavoidable.

I was reviewing an agent's work and noticed it had been claiming tasks as complete without actually doing the work. It reported everything as fine but when I challenged it, the agent admitted taking shortcuts. A convention was needed to require explicit state updates, so I put in place a task checklist system. It's not a trust issue. The models just need clear structures to follow. That's a recurring theme with this work: better conventions lead to better results.

I also learned which tasks justify the most capable model. Strategic work, writing, and complex decisions benefit from the best model available, but routine file scaffolding and handover updates don't need it. The difference shows in speed. A lighter model handles simple tasks in seconds where a heavier one takes noticeably longer, and if you're paying per use rather than a flat plan, the cost adds up too. It sounds like a small thing until you're running several sessions in parallel and a heavier model is still churning through a handover update while you're waiting to start the next project.

Then there are the invisible failures, the ones that don't produce error messages. An agent confident it's working in the right project directory turns out to be somewhere else entirely, and without conventions this happens a lot. Agents that archive messages before completing the actions in them. Getting them to follow the conventions reliably is one of the harder problems, and it's still ongoing. Over twenty documented patterns now, each one born from something going wrong in real client work.

Why Better AI Won't Fix This

If you're running multiple projects across multiple clients, a smarter model doesn't help much when it still forgets everything between sessions. The AI is already good enough but the coordination problem stays the same. What's missing for most people is the infrastructure and conventions that make it consistently useful across real work.

Most small businesses are still figuring out where AI fits. If you're starting to rely on it across multiple projects, the ceiling comes quickly. There's too much context to carry manually, too many sessions starting from scratch, and you end up being the human messenger between tools that can't talk to each other. The temptation is to stitch together automation workflows to fix this, but that's plumbing, not infrastructure. It breaks when any component changes. Building on the vendors' own tools means they maintain the foundation. You just maintain the conventions and customise them for your needs.

The hard part was never the AI but the conventions, the memory management, the communication protocols. Boring problems that determine whether AI actually works across real projects or just impresses you in a single session. I've solved it for my own business and I build this infrastructure for others. If any of this sounds familiar, I'm happy to talk through it.

Common Questions

Do I need to be technical to set this up?

To operate it, no. The conventions are plain text files that AI agents read and update. You don't write code or manage infrastructure day to day. Setting the system up does require technical knowledge (which is where I come in), but once it's running, working within it doesn't.

What AI tools does this work with?

Any tool that can read files in a project directory, which is most of the capable ones now. I currently use four different vendor families. Because the conventions are plain text with no vendor-specific dependencies, new tools slot in without changes. Given how quickly things shift in this space, that flexibility has already proved its worth several times over.

What happens if I stop using AI agents?

Everything is in markdown files. Your project state, history, issues, and accumulated knowledge are all human-readable and useful whether or not you're using AI. You'd walk away with better project documentation than most businesses have, which isn't a bad outcome regardless.

This article is part of an ongoing series on how Another Cup of Coffee is adapting to AI. Explore all articles in this series.

Footnotes

Featured image photo by Matt Benson on Unsplash.

Building an Operating Environment for AI Agents

Anthony Lopez-Vito — Thu, 15 May 2025 13:20:00 GMT

Over the past twenty years I've managed server infrastructure, built WordPress sites, handled data migrations and put together architecture specs for clients across multiple organisations. If you juggle multiple clients you'll know the feeling. Every project has its own context, its own history, its own set of things that need to happen next. Even when you use some sort of project management tool, a lot of the details still need to live in your head. Furthermore, every time you switch between projects, you need to reframe your mindspace to recall where a particular project is in that particular moment in time.

I've now unexpectedly solved this problem by building a coordination system that lets AI agents work across projects, clients, and organisations. It wasn't something I set out to build and instead, it just sort of happened organically as I began incorporating agentic coding tools into my everyday workflow. I've started calling it an Agentic Operating Environment, or AOE. Essentially, it's a set of file-based conventions that give AI agents persistent memory and a way to coordinate across projects and vendors.

The Problem That Crept Up on Me

I was already using AI seriously across my projects for a range of different tasks like writing code, research and troubleshooting, drafting client documentation, and processing data. The problem was continuity. Every new conversation started from scratch and I'd spend the first ten minutes of every session re-explaining what the problem or project was about, what had been done, and what needed to happen next. I'd have to prepare and manually upload files to give context. Switch to a different AI tool and the whole thing started from zero. This is fine for a one-off task, but it was a real hassle for working on a dozen active projects across multiple clients.

Then context files appeared with Claude Code introducing a file the agent reads at the start of every session, giving it project background and instructions. Other tools followed with their own versions and suddenly agents could pick up where the last one left off. I remember thinking this changes everything.

Most people were writing code with these tools but I was now starting to run my business through them. For that purpose, knowing about one project at a time wasn't nearly enough. I needed agents that understood what was happening across projects: what's blocked, who's waiting on what, which client deliverable depends on which internal task finishing first.

This problem opened up a bigger question. If an agent can read a context file, what else could you put in it? Could you give it genuine working memory, like what happened last session, what's blocked, what another project needs from this one? Also, what if one agent's work needed to inform a different project? Could you pass that context along without me being the human messenger as was needed in the web versions?

What I ended up with is a few things that work together::

Working memory and project context so agents know what happened last time and
understand the project
A memo system so they can talk across projects
Vendor-neutral conventions so I'm not locked to one AI provider
Specialised agents each handling a different area of work
Utility agents that manage the environment itself: a coordinator for cross-project visibility, a sysadmin for machine configuration, a configurator that scaffolds new projects
A factory that deploys new agent environments from templates

The individual pieces aren't complicated. Getting them to work together reliably across dozens of projects is where the time went, and what emerged is an architecture that looks fundamentally different from how most people structure their AI assistants.

It Doesn't Look Like Much

New AOE deployment for our website manager

It doesn't look revolutionary. It's a terminal interface that's been used since the earliest days of computing. But what's happening in that conversation is that I described what a project needed in plain English and an agent built the entire working environment: context files, state tracking, communication channels, vendor-specific instructions. No commands to remember, no forms to fill in, no setup wizard, just a description of the outcome I wanted.

This is what I mean by "operating environment". It's not an operating system that manages hardware and device drivers, but something that sits above all of that. Where your OS gives you a graphical or command line interface to the computer (windows, menus, mouse clicks, command parameters to remember), this gives you a natural language one. You just describe what you need in plain English and an agent works out how to get it done.

What surprised me is how little custom code this requires. Tools like Claude Code, Codex, and Gemini CLI already ship with everything you need to get started. They read and write files, run shell commands, search codebases, and follow instructions from context files. I'm not stitching together third-party tools and hoping they still work next month. Instead, the foundation rests on core features that the vendors build and maintain.

The hard part is more the conventions than the tooling. For example, what goes in each file, how to draw boundaries between projects, how to keep agents following the rules session after session. That's where the time went.

This started off as a simple improvement for one client but has now completely changed the way I use a computer and manage my projects.

Working Memory

Every project gets a handful of markdown files that serve as the agent's working memory. A project brief (BRIEF.md) captures confirmed knowledge that changes slowly like what the project is, who's involved, what's been decided about scope and technical direction. A state file (STATE.md) tracks what's happening right now and what needs to happen next. An archive (HISTORY.md) holds older progress that isn't immediately relevant. Other files capture reusable patterns (INSIGHTS.md) and whatever domain context the agent needs. The whole lot sits in a git repository, so nothing falls through the cracks and every change is auditable.

Here's what a typical project looks like on disk:

project-root/
├── BRIEF.md           # Confirmed project knowledge
├── CLAUDE.md          # Agent instructions
├── STATE.md           # Working memory
├── HISTORY.md         # Archived progress
├── INSIGHTS.md        # Reusable learnings
├── memos/
│   ├── incoming/      # Unprocessed messages
│   └── archive/       # Completed messages
└── docs/              # Project-specific reference

If any of that sounds abstract, the files map to things you already know:

File	Purpose
BRIEF.md	What the project is, who's involved, key decisions
STATE.md	What's happening now, what's next
HISTORY.md	Archived progress
INSIGHTS.md	Reusable patterns and gotchas
CLAUDE.md	How the agent should behave

It works in layers, with the agent reading STATE.md at the start of a session, doing its work, and updating it when it's done. Here's what a real one looks like. It's anonymised, but the structure is genuine.

## Quick Reference

| Key | Value |
|-----|-------|
| Project Path | ~/Projects/ClientA/web-dev |
| Last Updated | 2025-09-28 |
| Last Agent | Claude Code |
| Current Focus | Header component refactor |

## Current Status

Theme migration 80% complete. Navigation and footer done,
header still needs mobile breakpoints. Blocked on logo
asset from client.

## Recent Progress

### 2025-09-28
- Completed footer template with accessibility fixes
- Agent: Claude Code

### 2025-09-26
- Migrated navigation patterns from legacy theme
- Agent: Gemini CLI

## Next Actions

1. [x] Migrate navigation patterns
2. [x] Rebuild footer template
3. [ ] Refactor header component (blocked: logo asset)
4. [ ] Cross-browser testing

## Handover Notes

Header refactor is ready to go once the client sends the
logo. SVG preferred, PNG fallback. The mobile nav uses a
slide-out pattern, not a dropdown. See docs/nav-spec.md.

Every new session picks up exactly where the last one left off. The agent knows what's done, what's blocked, and why. Older entries get archived periodically to keep the working file lean.

Pick the Right Tool for the Job

I use Claude Code, Codex, Gemini CLI, and DeepAgent across different projects, and each has strengths for different types of work (and some genuinely maddening blind spots, but that's a longer conversation). The system doesn't care which one you pick.

Each project carries vendor-specific instruction files like CLAUDE.md for Claude Code, AGENTS.md for Codex, GEMINI.md for Gemini CLI. DeepAgent handles its configuration through its own rules system rather than a markdown file. These files tell the agent how to work in this particular project, covering things like session protocols, coding standards, and how to handle state updates. The content differs per vendor because each tool loads instructions differently, but the conventions they enforce are identical. If I want to switch providers for a project, nothing breaks.

What those instruction files actually enforce is the same core loop. Read STATE.md and check for incoming memos, extract your action list, do the work, update STATE.md with progress and handover notes, commit. Every agent follows this regardless of vendor. The instruction files also cover git conventions (like always use the -C flag, never commit to another project's repo) and cross-project communication rules (send memos, don't edit other projects' files). The format is vendor-specific but the behaviour is nearly identical.

This is a deliberate choice as the AI vendor market is volatile, with pricing changes, shifting capabilities shifts, and new tools appearing constantly. Last year's best option might not be this year's, and if your operation depends on one provider's way of doing things, a pricing change or service outage becomes a showstopper.

Claude API errors? Launch another vendor's model and keep working.

With vendor-neutral conventions, I simply run another vendor's agent and the project keeps running. It's a standard part of my workflow. Also, because the conventions are just files, there's nothing stopping you from running local models if your hardware is powerful enough. The system doesn't care whether the AI is in the cloud or on your own machine.

Cross-project Messaging

The agents needed to communicate across projects just as human team members do. For example, an infrastructure change in one might affect web development in another, or a content decision might depend on input from project management. However, the agents lived in separate project directories with no native way to talk to each other.

Initially I would let agents edit files directly in other projects. This was obviously not workable very early on when an agent tidied up what it thought were stale files that another agent needed. The fix was obvious as my university research was in multiprocessor computing, and this is a solved problem. Also, Linux processes don't scribble in each other's memory; they communicate through pipes and message queues. Early bulletin board systems worked the same way: post a message to a board, the recipient reads it when they next connect. The principle hasn't changed in decades: send a message, let the receiver deal with it in its own time.

Same principle here. Instead of agents editing each other's files, they send structured messages (I call them memos) into each other's memos/incoming/ directories. The receiving project picks them up at its next session then archives any that have the necessary actions completed. Because the memos are plain text files with naming conventions, they work across any AI tool that can read files. A Claude agent sends a memo, a Gemini agent picks it up, and the vendor boundary becomes invisible.

A sysadmin agent sends a bug to the project's developer agent.

The files are named MEMO-<topic>.md and follow a standard format. Here's one (anonymised) where a web development agent is notifying an infrastructure agent that a deployment is ready:

# Memo: Staging Deployment Ready

**From:** web-dev @ ~/Projects/ClientA/web-dev
**To:** sysadmin @ ~/Projects/ClientA/sysadmin
**Date:** 2026-02-28
**Subject:** Theme migration ready for staging

---

## Purpose

Header refactor is complete. Ready for staging deployment.

## Content

All templates migrated and tested locally. No new
dependencies. The only change to server config is the
new image optimisation path in the nginx rules
(documented in docs/nginx-changes.md).

## Action Required

- [ ] Deploy to staging environment
- [ ] Verify nginx config change
- [ ] Run smoke tests and report back

---

## Completion Notes
<!-- Receiving agent: complete this section before archiving -->

The receiving agent reads the memo at its next session, works through the checkboxes, fills in the completion notes, and archives it. The checkboxes are the accountability mechanism and a memo can't be archived until every action is ticked off. At least, that's how it's supposed to work; in practice, agents occasionally skip steps or archive memos prematurely. Getting them to follow the conventions reliably is one of the harder problems I've had to solve.

Putting Agents to Work

I started with one client who had particularly complex needs. Instead of one general-purpose AI assistant, I created specialised agents, each handling a different area like systems administration, web development, content curation, project management, research, document generation. Each agent has its own working memory and domain expertise.

Then I deployed the same approach on a second client, and the cognitive burden genuinely lifted. The agents remembered every detail I used to carry around in my head, across two separate clients, without mixing anything up. I stopped being the person who has to remember everything.

Sitting above the project agents is a coordinator which is a dedicated agent whose job is cross-project visibility. It reads the state of every project (44 at last count, across 14 organisations), tracks what's blocked, routes memos between projects that don't know each other's paths, and maintains a dashboard of the whole operation.

The way it knows what's happening is straightforward because each project is registered in a YAML file:

- name: client-a-web
  path: ~/Projects/ClientA/web-dev
  organization: client-a
  description: WordPress theme development and maintenance
  tags:
    - web
    - wordpress
  dependencies:
    - client-a-infra
  registered: 2026-01-15

A scanner reads STATE.md from every registered project and builds a view of what's active, what's blocked, and what's gone quiet. The mechanism is simple but the visibility it gives you is automatic. No one has to update a dashboard or fill in a status report as the agents' own working files are the source of truth.

An Agent That Builds Agents

When the conventions started working reliably, I wanted a way to replicate them without manually setting up every new project, so I built what amounts to a factory agent. I give the agent a project brief and it scaffolds everything in one step. The output is a complete project directory including: - instruction files for each AI vendor, with session protocols, git conventions, and cross-project communication rules baked in; - a STATE.md with the Quick Reference table and empty sections ready to fill; - a memos directory; - its own README, HISTORY.md, INSIGHTS.md, and whatever domain-specific extras the project type calls for.

Different project types get different scaffolds. A sysadmin project gets server inventory sections and SSH configuration templates. A bookkeeping project gets invoices and reconciliation directories. The conventions are the same across all of them but the domain-specific bits vary. I can point the factory at an existing working project and say "set up a new one like this, but for Client B." It uses the existing project as a reference and adjusts for the new context.

The factory has deployed over forty projects so far, each one inheriting the same coordination conventions. A new project goes from nothing to a working agent environment in one step.

Star vs Mesh

Now that you've seen all the pieces, it's worth stepping back to look at the structure of what emerged because it's not the shape most people build.

Most AI assistant frameworks use a hub-and-spoke topology. Daniel Miessler's PAI is probably the best-known example with one central assistant, one identity, one memory system, and skill modules for different domains. Kenny Liao's personal assistant follows a similar pattern, with domain-specific plugins loaded into a single runtime. The skills are more sophisticated than they look. PAI's chain into each other, and Liao's use progressive context loading. But the structural principle is the same: one hub and everything flows through it.

My system uses a mesh topology. I first came across mesh architectures in the early 2000s while evaluating mesh networking technologies for a Japanese trading house. The concept isn't new, so applying it to AI agent coordination seemed like a natural fit.

Each project is an autonomous node with its own state (STATE.md, HISTORY.md), its own instructions (CLAUDE.md, AGENTS.md, GEMINI.md), and its own agent identity. No single node holds everything, and nothing requires them to sit on the same machine. Projects communicate asynchronously via memos, like Unix processes communicating through pipes.

	Star (PAI)	Mesh (AOE)
Context	One context for everything	Scoped per project; agent only sees what it needs
Boundaries	All domains share memory	Client A's data never enters Client B's context
Failure	Centre goes down, everything stops	One project breaks, others unaffected
Scaling	Gets heavier as you add domains	Adding a project is just adding a node
Vendor	Tied to one agent runtime	Each project picks its own AI vendor
Collaboration	Implicit (shared memory)	Explicit (memos with structured actions)

None of the major agent frameworks frame this as a deliberate choice. Anthropic calls their pattern "orchestrator-workers". LangGraph calls it "supervisor". CrewAI calls it "hierarchical process". They describe what the orchestration does, not what shape it takes. The structural decision goes unnamed, which is probably why it goes unexamined.

The hub model is optimised for one person wearing many hats, like a freelancer who does health tracking, writing, finance, and coding through a single assistant that knows their whole life. My model is optimised for many projects with clear boundaries, where a web development agent for Client A must never see Client B's project data, where cross-project coordination needs to be auditable (every memo is in git), and where different projects might need different AI vendors entirely.

The word "mesh" has started showing up in enterprise AI writing too, but there it means container orchestration, agent registries, policy enforcement. This is infrastructure for managing fleets of agents across an organisation. What I'm describing is much simpler concept of project directories that talk to each other through plain-text files.

It's the same underlying insight as PAI and similar tools. The filesystem is the context system, markdown files are the medium, but there's a key difference. Those systems use the filesystem for context while mine uses it for coordination too. Memos route between projects, state files track handoffs, every change lives in git. The filesystem is both the memory and the message bus.

Where It Stands

That's the full picture. Working memory, memos, vendor-neutral conventions, specialised agents, a factory to set up new projects, and an architectural structure that none of the major frameworks are talking about yet. The building blocks are markdown files, naming conventions, and structured messages. No database (unless you specifically need it for a project), no platform, and no special software. However, the judgement calls about where to draw project boundaries, how to scope agent responsibilities, and how to keep conventions working reliably across a growing number of projects are what took months of trial and error across real client work.

As of writing, there are 44 active projects across 14 organisations. This is real production work involving published websites, live content, architecture specifications, server infrastructure. None of this is proof of concept or theorising.

A few design principles fell out of the process that I think are worth naming:

Vendor-agnostic. Works with any AI that can read markdown. No proprietary formats, no lock-in.
Convention-based. No runtime dependencies, no database, no platform to maintain. It's files and naming conventions and that's it.
Distributed boundaries. Each project is its own island. Client A's working files never enter Client B's context unless you explicitly tell an agent to share something. Cross-project communication goes through memos as standard.
Human-in-the-loop. I approve every consequential action so the agents do the legwork while I make the decisions.

Right now the whole thing is passive infrastructure. I start a session, the agent picks up where the last one left off, then I close the session. The direction is toward semi-automated, where events trigger sessions and memos route themselves. But that's a story for another post.

It's not finished (honestly, I doubt it ever will be as it continues to grow and improve), but it handles real client work across multiple organisations every day. There's more to say about how this compares to other approaches and where it goes next, and I'll get to that.

If you're running multiple projects and spending too much time being the human messenger between them, this approach works. I'm happy to talk through how it might apply to your setup, drop me a line.

This article is part of an ongoing series on how Another Cup of Coffee is adapting to AI. Explore all articles in this series.

Why We Keep Using ChatLLM Despite Everything That's Wrong With It

Anthony Lopez-Vito — Mon, 20 Jan 2025 12:45:15 GMT

This article is part of a series on our journey and how we at Another Cup of Coffee are adapting to Artificial Intelligence. Competing in a market dominated by larger agencies means we have to be smart and a little bit scrappy, willing to experiment with new tools and alternative ways of working.

Over the past two years, AI has become a crucial part of our strategy, helping us punch above our weight and deliver more value to our clients. In this post, I take a closer look at a tool that has become central to our workflow: ChatLLM from Abacus.AI.

ChatLLM has been an incredibly useful addition to our toolkit, but it's certainly not without its drawbacks. While Abacus.AI's pricing makes their offering compelling, there are many areas where it falls short, such as in poor documentation, almost no support, and unreliable implementation. Nevertheless, ChatLLM has been a valuable tool, and I'll dive into our experiences with it, covering both the positives and the frustrations.

This post has not been sponsored by Abacus.AI, but if you're interested in ChatLLM, we have a referral link for those who want to give it a try.

How AI Has Changed Our Work

Before I get into ChatLLM specifically, it's worth briefly mentioning how AI has helped our day-to-day work. We've found that with the right AI tools, we can take on projects that would normally need more people, and we spend a lot less time on boring repetitive tasks, such as data cleaning and processing.

The quality of what we deliver has gone up and clients get better value while we continue to keep our pricing competitive. There have been many cases where we've been able to offer insights that used to require bringing in highly-paid specialists.

For example, there have been a number of projects where we've been able to save our clients money by delivering close-to-final draft documentation and reports that required specialist expertise. Instead of immediately hiring costly third-party consultants, clients simply had our AI-generated drafts reviewed by their in-house counsel, significantly reducing professional fees.

We've also cut expenses by using AI assistants to rapidly code custom, single-purpose tools rather than purchasing expensive off-the-shelf software or subscriptions. Those costs can add up significantly, especially for small agencies like ours. Such bespoke utilities to solve specific one-time project challenges could not have been feasible without AI.

Being an early mover into AI integration has given us insight into the massive shifts coming to the workforce and to society in general. We have already started adapting our business and skills to thrive in this new environment so I'm now more confident about Another Cup of Coffee's future.

What We're Using

We've tried loads of AI platforms over the past couple of years. Some stuck around but many others didn't. Aside from ChatLLM, we regularly use a range of other tools including:

October 2025 update: We've replaced a number of tools with Claude Code, which has proven superior.

They all have their specific use-cases but ChatLLM is definitely the one I personally reach for most often.

ChatLLM from Abacus.AI: What's Good and What's Not

What Is It?

As its name implies, ChatLLM is Abacus.AI's chat-based AI platform that gives you access to a bunch of different LLM models through one interface. You pay $10 US Dollars per user per month, and get access to the most popular models like ChatGPT, Claude Sonnet, Gemini and DeepSeek. Models are released so frequently that I haven't bothered to include the version numbers.

Abacus.AI doesn't just give access to multiple models. You get specialised tools like CodeLLM, their AI-assisted VS Code editor, and AI Engineer to help you build custom chatbots and AI agents.

Why We Like It

It's cheap. That's it. $10 a month for all those models is excellent value as we'd be paying over $50-$100 per month if we subscribed our most-used models individually. This means we can use the strengths of the different models rather than trying to make one model do everything.

We use it for all sorts of things: writing first drafts of client proposals; creating documentation or reports; helping debug and improve code; project planning; summarising project progress; and general brainstorming. It's not all great and the low price comes at other costs.

The Annoying Bits

Poor Documentation

The documentation is absolutely terrible, outdated and severely incomplete. Help pages casually reference features and interface elements without any explanation, expecting you to be familiar with their terminology for the various screens and settings. I've wasted so much time trying to figure out basic stuff that should be clearly explained.

No Customer Support

Customer support is also non-existent. I've sent questions about specific features and they go into a black hole. Good luck to you if you encounter problems. I suspect they're putting all their effort in supporting enterprise clients. If you're a small or medium-sized business, this will no doubt make you wonder if this is a solution you can trust with production-grade tasks. Right now, we don't use it for any client-facing solutions and a big reason is lack of customer support.

Terrible Interface

The interface is horrible too. It feels like it was designed by engineers who just bolted on features and stuck them in weird places. Aspects such as their version of the ChatGPT Playground are a complete kludge. You can't expect the kind of seamless interaction with your work that's available on ChatGPT's user interface.

CodeLLM - A Waste of Time?

CodeLLM is Abacus.AI's answer to AI-assisted code editors like CoPilot, Cursor and Windsurf. However, it feels like someone's half-hearted attempt at a side project, thrown together after hours and released, then forgotten. I won't even bother listing its problems and I recommend not wasting your time even trying it. Maybe CodeLLM will get better over time but I really don't see why it's available at all. Stick with the more well-known options.

Unreliable Custom Agents

When this review was first posted in January 2025, I mentioned my love-hate relationship with the custom agent feature. Back then, I found it useful for building agents to handle tasks we do regularly, such as generating documents, manipulating our back-office financial transactions, or providing chat access to local knowledge bases. I also mentioned problems with poor documentation and unexpectedly burning through credits using the AI Engineer feature.

Now I've stopped using it altogether because they've become unreliable. For some reason, previously working agents will hang, producing no output, or spit out an error. I did try contacting Abacus.AI support but there was no response or even acknowledgement that they'd received my message.

Unclear Pricing and Service Limits

You'd think that at $10 per user per month, you'll have a good idea of what you'll be paying. But that's not the case. Each user is allocated 2,000,000 compute points per month. What exactly that means is not at all clear. Here's Abacus.AI's explanation:

"Compute points are NOT TOKENS. They are simply a measure of usage of ChatLLM. With 2M compute points, you will be able to send 50,000+ messages on some LLMs in a month. 1,000,000 (1M) compute points can be as much as 70,000,000 (70M) tokens on some LLMs."

OK, so 50,000+ messages sound a lot and most months we're well within the limit. However, a few times I managed to burn through most of my compute points in a couple of afternoons of using AI Engineer. How? No idea.

New Features (mid-2025)

Abacus.AI has added a few more features to ChatLLM since I originally wrote this post:

DeepAgent: an autonomous agent that can help you with tasks like research, planning or building apps.
Tasks: a scheduling and automation utility designed to run AI-powered actions at certain times, intervals, or triggers.
Apps: no-code and full-code methods for launching apps.
Projects: a feature to organize chats, files, and workflow instructions into folder workspaces.
RouteLLM: a routing mechanism to send your queries to the best underlying language model.

Because of my poor experience with ChatLLM Custom Agents, I really haven't bothered to try out DeepAgent, Tasks or Apps. These new features may be worth some experimentation if I were a reviewer or YouTube AI influencer, but my focus is on getting work done. When you're running a business, you rarely have time to play with new things, and I feel that Abacus.AI wasted my time with Custom Agents.

Projects and RouteLLM are different though. They're built-in improvements to the chat interface and are probably my two most favourite ChatLLM additions so I'll spend a bit of time talking about them.

ChatLLM Projects

This feature is exactly like ChatGPT Projects and there's not much explanation needed here. You can organise chats into folders for easy reference. They're perfect for working on different areas within your business. In some ways, it has replaced ChatLLM's flaky Custom Agents implementation for my needs.

I'll have different 'agents' in project folders where I copy and paste prompts from old chats to get certain types of work done. For example, I'll have projects for proposals, coding tasks and client needs, like contract review or support requests. Each project can have its own custom instructions and files for context. This is perfect if you want to quickly create a task-specific AI without having to mess around with building an actual agent.

RouteLLM

When Abacus.AI first deployed RouteLLM, it was just one model among many alongside GPT, Claude, and Gemini. Now it's the default option. Your chats will go through RouteLLM unless you manually set your model.

It does a fairly good job of routing your chat to the right model but seems to favour OpenAI's GPT-5. This could be for my own use-cases though. It will sometimes inappropriately route queries to Gemini 2.5 Flash, and I suspect this is Abacus.AI trying to reduce their API costs.

But what's really great is the Regenerate using option. If you're not quite happy with a response, or you want to see how a different model will respond, just click the model button underneath. This is a massive time-saver. The alternative would be to switch your session to another model provider or use yet another service like Boxchat or chatplayground.ai.

Is ChatLLM Worth the Price?

Despite all those frustrations, ChatLLM is the AI tool we use most, and this is still the case many months after originally posting this review. The value it provides is just too good to ignore. We've become used to its shortcomings and found ways around its poor interface.

I've been tempted to re-subscribe to ChatGPT or Claude whenever they release a new model but stopped to think: is it worth the extra expense when they'll be available on ChatLLM within days?

If you're a small agency or freelancer and you can put up with some friction in exchange for powerful capabilities at an affordable price, ChatLLM is definitely worth looking at. Just don't think you'll get anywhere near a polished experience or helpful support for your $10.

Being Transparent

I should mention that Abacus.AI is active in advertising through content creators, especially on YouTube. We haven't received anything for this review and I'm simply sharing our experience as paying customers. I genuinely find the tool useful and worth recommending, despite its many problems.

Give It a Try

If you're curious about what ChatLLM might do for your business, I think it's worth trying for the price of a couple of cups of coffee. Use our referral link here. (We'll get $5 if you sign up but they don't say what you'll get. Probably nothing.)

I certainly won't call myself an Abacus.AI fan, but I do think other small agencies and freelancers might benefit greatly from this tool, warts and all. For us, the trade-offs have been worth the price and like any tool, what matters is whether it fits your specific needs and how you work. ChatLLM definitely isn't perfect, but it's been really useful for us so for the price, you'll lose very little to find out if it works for you too.

Try ChatLLM Now

Use our referral link to try ChatLLM.

Still Alive: A Micro Agency's 20 Year Journey - Part 2

Anthony Lopez-Vito — Thu, 14 Nov 2024 15:28:15 GMT

In Part 1 of Still Alive: A Micro Agency's 20 Year Journey, I reflected on Another Cup of Coffee's journey from a one-person freelancer operation running from a rented mailbox address, to setting up in a trendy unit Westbourne Studios. Here I recount the initial challenges we faced as an agency and how we survived by transforming the way we worked.

Finding a Balance: Growth and Resources

A few doors down sat what I wanted for our future. It was a large and successful media agency staffed with very confident ex-BBC people. They had loads of sales reps and account managers. I think it was among the first generation of the global web agencies we have today.

The founder was famous in our circles for saying that he didn't bother getting out of bed for less than £30,000. That amount is common for web projects now but saying this in the early 2000s was quite grandiose and flamboyant. Though we were charging a fraction of their rates, I imagined someday reaching their scale.

However, running a small web agency in London is challenging to say the least and scaling was the biggest problem. We were too small for large projects, but small projects wouldn't pay for growth. It was a classic trap.

Sell and Keep Selling?

Looking back, I think the key to growing an agency of any size is to just sell. Sell and keep selling even if you're not sure you can deliver. This is why the large agency had so many sales and account managers. Other agencies I've observed over the years seem to have grown in this way: they are sales-heavy and make lots of nice promises. But I've never been comfortable with making promises unless I'm sure of them so our growth remained stunted.

Meanwhile, our office space wasn't really free. It came with a heavy cost in the form of commitments that took my time away from building the business. The elephant in the room wasn't that big agency but our premature attempt at playing big.

It couldn't be ignored for very long as I struggled to bring in the right projects to ensure everyone was paid. It became clear that the traditional office setup wasn't sustainable and I had to make some difficult choices, quickly.

Transforming Into a Cloud-first Virtual Agency

Goodbye Westbourne Studios

Survival often means letting go of how you imagine things should be. Our biggest advantage was that we were scrappy and nimble so I decided to use it. We didn't actually need a trendy office and everyone was more productive without the daily commute into West London.

Within a couple of weeks of making the decision, we transformed into a cloud-first operation. I also hired more freelancer friends from the Philippines to fill our skills gap. Suddenly, Another Cup of Coffee was a fully remote virtual agency, years before the concept became popular.

Digital Nomad and Prevailing

Being cloud-first and remote meant that I could do the digital nomad thing for a while too, working out of all sorts of unconventional places. This opened up the opportunity to pick up clients globally. Even now, the majority of our projects come from outside the UK.

Karl and Pafsanias moved on to other—almost certainly greener—pastures but by then we'd evolved into a collective of remote colleagues, forming teams as projects demanded. This lean and agile model allowed us to weather storms that have since sunk many of our contemporaries.

I can say with some sense of accomplishment that Another Cup of Coffee has outlasted all three of the ventures who shared our unit, and also that large agency I'd once admired. The key was our ability to try out different ways of working. The founders quite possibly sold the business and exited with large bonuses, but I'm after something different: an establishment that can be handed to another generation. (More about this will follow in another post.)

Moving Towards Specialisation

Our early advantages began to fade as remote work became mainstream and sites like Elance and oDesk gave even small businesses access to global talent. This rise in cross-border competition made it difficult to stand out by only offering general website services, and even our strong relationships with existing clients wouldn't guarantee the cash flow needed to keep the business afloat.

At the same time, Drupal's growing complexity turned maintenance into a huge drain on resources. Again it was time to adapt and the answer came from an unexpected direction.

I'd spotted a need for content migrations, specifically from Drupal to WordPress, and built up an expertise in data-heavy web projects. It was unglamorous and mundane engine-room work so few agencies were interested in training up their talent for such a niche skill.

Version 1 of our custom-built Drupal to WordPress Migration Tool

Leaning Into Your Nature

But it was necessary work that happened to fit my meticulous nature and long experience with databases. Further, businesses were beginning to realise the value of data and content while most of our colleagues were focused on dazzling user experiences. Data was our differentiator.

Another Cup of Coffee shifted to becoming a boutique data migration consultancy with myself as principal consultant supported by a few freelancers. Unexpectedly, I became a pioneer of Drupal to WordPress migration services and was recommended by WP Engine in a whitepaper guide.

This ultra-narrow specialisation gave Another Cup of Coffee a much-needed distinction for almost ten years. Run a web search now and you'll see many solutions and services for content migrations but we were one of the first.

Looking Forward

Since those early days, we've kept evolving alongside shifts in technology and ways of working. I can't claim that any of it was planned but I can say we've always been willing to change, just slightly ahead of our peers. Throughout this journey, I've learned that survival isn't about being the biggest or the most innovative. You survive by keeping customers happy and watching out for dust on the horizon, ready to move before a stampede arrives.

We once embraced virtual offices, the cloud-first paradigm and global remote working before they were common. Now we find ourselves very suddenly confronted by something new. I think it's obvious that AI will be disrupting our lives in ways that will be hard to avoid. It's again time to learn to adapt just as we always have.

This is the first in a series of posts about our journey and how we're adapting to Artificial Intelligence in our lives. I do hope you'll follow along with me as I share what I've learned.

'Still Alive' from the Portal game credits. I never played the game but I've always enjoyed the sound and lyrics.

Footnotes

Featured image photo by Lil Mayer.
Still Alive is by Jonathan Coulton. The official video with Sara Quin and Dorit Chrysler can be found here.

Secure Your AI Workflow Using Local Tokenisation

Anthony Lopez-Vito — Tue, 12 Nov 2024 13:59:03 GMT

Secure your AI workflow with local tokenisation. PaigeSafe is a lightweight tool perfect for small agencies and freelancers handling sensitive client data in ChatGPT, Claude and other AI tools.

If you've spent any time at all using cloud-based LLMs like ChatGPT or Claude for client work, you've probably had that voice in the back of your head kick in: "Should I really be pasting this into a chat?" I'm sure that moment of hesitation is all too familiar for those who have started to integrate AI into work workflows.

Every day, many of us paste sensitive content into AI tools—client data, business strategies, internal documents—often without really thinking about where that information ends up. That data potentially becomes part of training sets, risking leaks by cropping up in future chats with other users. For freelancers and small agencies handling confidential client work, Large Language Models (LLMs) create a real dilemma. They're too useful to avoid but carefully sanitising content is a real chore.

Enterprises solve this with expensive solutions which are overkill and far too expensive for the rest of us. Those who want to take advantage of LLMs have been left with carefully reading through documents and running manual search and replace for names and numbers. This is tedious, error-prone and still stands a high likelihood of data leaks. Unfortunately, taking unnecessary risks with client data, spending ages on manual anonymisation, or avoiding AI tools altogether when working with sensitive information is no longer a good option to remain competitive.

Introducing the PaigeSafe Document Security Tool

PaigeSafe is a document security tool that helps protect your confidential information when using Large Language Models (LLMs) like ChatGPT and Claude. It uses the process of tokenisation by replacing sensitive data with non-sensitive placeholders. We originally built it as an in-house tool because we faced these exact same challenges. As a small team, we needed something that just worked without the expensive licenses and high learning curve.

PaigeSafe is currently in the prototyping stage to test if there is demand for this type of utility. It offers basic functionality, and the code lacks robust error checking. However, since it is intended to be run locally, there is minimal risk to your documents. All it does is offer a convenient way to search and replace text before you paste or upload sensitive text to LLMs. I regularly use it to sanitise my own documents.

Uses and Limitations

PaigeSafe does not try to offer an enterprise solution for those who need to meet strict compliance regulations. Here's where it fits in the document security landscape:

Perfect for: Freelancers, small agencies, independent developers
Good for: Regular business documents, client communications, project data
Not for: Banking systems, medical records, top-secret government files

PaigeSafe is a lightweight tool that helps you avoid accidentally exposing sensitive information to AI models. If you're handling typical client work like website data, marketing plans, business strategies, and project specs, this solution is for you. It's perfect for those, "I need to run this past ChatGPT but shouldn't share the client's name" moments. Or when you want to analyze customer feedback without exposing individual identities.

If you work for a financial institution, healthcare provider, or government contractor, this solutions of course will not be for you.

Where to Find it

The tool is built using Python and the Streamlit framework but if you use Docker, it can be easily installed by pulling the PaigeSafe image from Docker Hub. For more information, please visit the dedicated site at paigesafe.com.

Remember that it is still very much an early prototype but more useful features will follow. Please send feedback to paigesafe@anothercoffee.net

How to install PaigeSafe

Find out how to install the prototype application by following the instructions on the PaigeSafe website.

Still Alive: A Micro Agency's 20 Year Journey

Anthony Lopez-Vito — Tue, 15 Oct 2024 15:28:15 GMT

Recently I was handing over tasks to an AI when it struck me how much my work has changed. It's been two years since OpenAI released ChatGPT-3.5 but things were so different when I first started Another Cup of Coffee. One of my biggest problems, almost twenty years ago, was figuring out how I'd hire skilled people with no budget. Now I'm learning to understand how to use something that's been trained on all the world's knowledge, while paying less than the price of lunch.

This change is astounding so I thought to reflect on our journey. I'd like to tell the story of building Another Cup of Coffee from a one-person operation to a survivor of multiple technological revolutions. It's a story about the decisions, both good and bad, that led to where we are now. Most of all, it's about learning to adapt before a shift in paradigm.

I'd like to share this now because I believe the developments in Artificial Intelligence have brought us to another turning point. It's once again time to adjust to new ways of working. Before I get into that, I think it's important to look back on the past to understand how we got here.

Finding Our Path

Another Cup of Coffee has never positioned itself as a trailblazer. It was founded on the principles of reliability, technical expertise and long-term client support. We focus on the behind-the-scenes work so that our clients can shine. And while we don't try to be the first to adopt every new trend, we have found there's value in selecting tools and methods that make our services better.

Over the past two decades, our approach has positioned us to adapt to industry shifts while ensuring that our clients remain happy with the core of what we do for them. This philosophy was a counterpoint to the early days of the web which was an experimental and somewhat chaotic scramble to try new technologies.

The Early Web

The web was very different in the '90s. I remember moving out of the comfortable walled garden of CompuServe into the wild web—and being completely underwhelmed. It was slow, even after upgrading to a blazingly fast 28.8K modem.

Browsing sites on NCSA Mosaic was confusing too but we netizens soon understood the Net to be a place without rules. And if you wanted something, you had to build it, so we did. We hand coded sites in Notepad, Vi, FrontPage or HotDog. (Some of you must remember HotDog, right?) We built and experimented and figured things out as we went along.

HotDog 1.0 web editor released in 1995

After university, I landed jobs working on mobile data synchronisation, building online communities, web databases, and rolling out the first mobile services. These concepts are taken for granted now but they were pioneering back then. People quickly integrated new technologies into their business and personal life, opening up different approaches for accomplishing everyday tasks.

Starting Out as a Freelancer

It was exciting work but I liked doing things my own way and set out as a freelancer in the early 2000s. I wore whichever hat would get work: technology analyst, database developer, systems administrator, network engineer, and of course, 'webmaster' (how quaint). Remote work wasn't a thing yet, so legitimacy meant having a proper business address.

People would blag desks from friends' businesses or pay for expensive serviced office space. I chose the quick and easy route: a rented mailbox address in Gloucester Road, London. Just a block away from the tube station and a short walk from Kensington Palace, it sounded legit and swanky! But no, by necessity I was working from home and operating a virtual office before it was the norm.

Fresh Coffee and Trendy Peers

After a few years as a solo freelancer, I realised that having a team behind me was necessary to take on more ambitious projects. When Another Cup of Coffee was formally established in 2006, it was a natural continuation of those freelancer years but with a more structured agency approach. The aim was to offer fully-functional but reasonably priced websites to small businesses, using a set of ready-built tools and an emphasis on customer service.

Many developers were still rolling their own custom solutions. They retained the do-it-yourself mindset of the early web and didn't realise that open source Content Management Systems had matured enough to offer production-ready web platforms. WordPress was still mostly a blogger tool so I chose Drupal because of its flexible content structure and growing module ecosystem. We offered complete web solutions at a fraction of the cost and development time needed by most other agencies.

Westbourne Studios

I set up in a client's spare meeting room in the trendy Westbourne Studios, near London's famous Portobello Road Market. Westbourne Studios was a space popular with creatives, musicians and media professionals which, after hours, transformed into one of Notting Hill's most popular nightclubs.

In exchange for free office space, I handled project management for the host company. We shared the unit with three other micro agencies in the cool creative media arena so as techs, we were somewhat out of place.

Potato phone photos of Westbourne Studios in the early 2000s

Our initial team was small but promising. My friend Lan handled technical support; Karl, a colleague I befriended from my first job out of university, took care of development; Pafsanias, a brilliant fresh graduate who responded to my Gumtree job ad, created the front-end eye candy; Benjor, another friend who ran a small design studio in the Philippines, was our remote designer. I focused on project and account management while trying to build up the business. Claire (not her real name) was in charge of sales.

Early Mistakes

We all gelled personally but I learned an expensive lesson with Claire. You see, she couldn't actually sell. Claire was a photographer looking for side work, and I thought her outgoing personality would make up for inexperience.

I was wrong. You need the right type of person in sales and she wasn't that person. It was my mistake. Perhaps I was motivated by the need to fit in with the other creatives in the building but in any case, it was a bad hire on my part. I really should have driven sales but I wasn't a salesperson either.

My mistake with sales was one of several that would lead to problems balancing growth and resources. In Part 2, I recount the initial challenges we faced as an agency and how we survived by transforming the way we worked.

This is the first in a series of posts about our journey and how we're adapting to Artificial Intelligence in our lives. I do hope you'll follow along with me as I share what I've learned.

Still Alive: A Micro Agency's 20 Year Journey - Part 2

In Part 2 of Still Alive: A Micro Agency's 20 Year Journey, I recount the initial challenges we faced as an agency and how we survived by transforming the way we worked.

Read Part 2 Now

Footnotes

Featured image photo by Emiliano Vittoriosi.
HotDog 1.0 screenshot from The Web design Museum.

Focus on your mission, not your tech - Another Cup of Coffee

The Practical Guide to Locking Down Claude Code

Table of Contents

Key terms for Claude Code security

The OS layer you already have

What you'll need

The sandbox path

Why not the sandbox for AI agent workflows?

The design principle: layered Claude Code security

Layer 1: deny permissions in settings.json

Keep credentials out of context

The sudo convention

Layer 2: the Bash guard hook

Why simple text matching for the hook script?

Per-project exemptions

Registering the hook

Testing your security setup

What's next for locking down Claude Code

Common Questions

Known Limitations

You may also like

Footnotes

VibeOps: Let AI Do the Prep, Not the Decisions

The Setup: AI Agents That Don't Deploy Themselves

Why Not Automate Deployment?

Keeping the Infrastructure Simple

How AI Agents Coordinate Deployments

Why Access Between Projects Is Deliberate

Security: The Part VibeOps Would Get Wrong

What VibeOps Should Actually Be

Getting from Vibe Coding to Production

Common Questions

You may also like

Trust, But Verify: What's Really Between Your AI Coding Tool and Your SSH Keys

What's been going wrong with AI coding tool security

So what's standing between the AI and your SSH keys?

What we're doing about it

A practical AI coding tool security checklist

Common Questions

You may also like

Footnotes

What OpenClaw Teaches Us About AI Agent Security

How OpenClaw Blew Up

It's Not Just OpenClaw

What We Actually Do

Conventions, Hooks, and the Agent That Went Rogue

Text Files Can't Execute Code

When Conventions Aren't Enough

What We Give Up

So What's the Takeaway?

You may also like

Footnotes

I Run Dozens of Projects with AI. The Hard Part Isn't the AI.

Too Busy for New Toys

Trapped in the Browser

Breaking Out

One Client, Many Agents

Teaching Agents to Talk

Working Memory

An Agent That Builds Agents

The Boring Bits That Matter

Why Better AI Won't Fix This

Common Questions

You may also like

Footnotes

Building an Operating Environment for AI Agents

The Problem That Crept Up on Me

It Doesn't Look Like Much

Working Memory

Pick the Right Tool for the Job

Cross-project Messaging

Putting Agents to Work

An Agent That Builds Agents

Star vs Mesh

Where It Stands

You may also like

Why We Keep Using ChatLLM Despite Everything That's Wrong With It

How AI Has Changed Our Work

What We're Using

ChatLLM from Abacus.AI: What's Good and What's Not