Epho Runs Claude Code with Curl

Epho is a Show HN project introduced by Burak that exposes cloud-hosted coding agents through an API. It deals with the boring but painful part of agentic coding: provisioning sandboxes, invoking different agents, collecting logs, and keeping runs alive when providers fail. The takeaway is simple: treating the runner as an API boundary can make experiments with Claude Code, Anthropic's coding agent, easier to test and easier to contain. Epho is an API layer for running coding agents such as Claude Code, Codex, or OpenCode inside managed cloud sandboxes.

Why one HTTP request got attention

The interesting part of Epho is not that it says “curl.” It is that the curl call stands in for a lot of invisible plumbing.

A bare sandbox gives you a machine. It does not automatically give you a checked-out repo, a prepared language toolchain, agent-specific invocation rules, useful logs, artifacts, retries, or a clean answer to “what changed?”

That is why developers cared. Many people building AI analysts, CI repair bots, or codebase assistants eventually rediscover the same chore: they are not only prompting a model, they are operating a small remote build system.

The trap is to confuse a nice API with a safe workflow. A one-request runner still needs boundaries around secrets, network access, file paths, branch names, and what counts as a finished job.

The runner is the real product surface

For Claude Code users, Epho is useful to study because it moves attention from chat to execution. The prompt matters, but the runner decides which repo the agent sees, which commands it can run, where logs go, and whether the result is a patch, a branch, or a pile of terminal output.

A concrete example: imagine a small Rails billing repo. A safe remote job might allow edits under app/services/invoices/** and test/services/invoices/**, run bundle exec ruby test/services/invoices, and return a diff plus test output. It should not see production credentials, deploy keys, or the whole company monorepo by default.

If you run Claude Code locally, the same shape applies. A small PreToolUse hook can block dangerous shell commands before the agent executes them:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python3 .claude/hooks/block-dangerous-bash.py"
          }
        ]
      }
    ]
  }
}

import json
import re
import sys

payload = json.load(sys.stdin)
cmd = payload.get("tool_input", {}).get("command", "")

blocked = [
    r"\bterraform apply\b",
    r"\bkubectl\b.*\bprod\b",
    r"\brm -rf\s+/",
    r"AWS_SECRET_ACCESS_KEY",
]

if any(re.search(pattern, cmd) for pattern in blocked):
    print("Blocked dangerous command in agent sandbox", file=sys.stderr)
    sys.exit(2)

That hook is not an Epho feature claim. It is the local Claude Code version of the same idea: put the hard boundary at execution time, not in a paragraph of instructions the agent may reinterpret.

Epho’s bet is that sandboxes should be boring

The project’s pitch is that sandbox work should be abstracted away. That includes configuring machines for agentic workloads, handling agent differences, dealing with unreliable sandbox providers, and preserving logs and artifacts.

That is a reasonable bet. The least glamorous code in an agent product is often the code that makes jobs repeatable: clone repo, install dependencies, run agent, stream events, collect output, clean up, retry somewhere else.

The objection is also reasonable. If a runner API hides too much, debugging gets harder. Security review also gets more serious, because the runner is now near source code, secrets, package registries, and sometimes internal data.

The practical move is to treat Epho like a runner boundary, not a magic agent boundary. You still decide the repo scope, the credentials, the allowed commands, the artifact contract, and the human review point.

Where Epho fits and where it is overkill

Epho is most interesting when you need to run many coding-agent jobs from another product or service. An AI analyst that opens PRs, a benchmark harness that compares agents, or a bot that repairs flaky tests all benefit from a single API that can start isolated runs and return artifacts.

It is probably overkill if one developer is using Claude Code in one repo and can already run tests locally. In that case, spend your energy on concise repo memory, a small set of hooks, and a repeatable review habit before adding remote orchestration.

This is where the broader agentic coding governance topic is useful, but the story here is narrower. Epho is about the runner layer. If your bottleneck is noisy agent interaction rather than remote execution, compare it with Huzzah Makes AI Coding Less Chatty.

The trap is building a platform because the demo looks clean. Try one job class first: a tiny refactor, a test repair, or a dependency update in a disposable branch.

Try Epho safely in one afternoon

Copy this run receipt before testing a remote coding-agent runner. Fill it out for one small repo and one boring task. If you cannot fill in a field, the job is not ready to leave your laptop.

runner: Epho
agent: Claude Code
repo: github.com/acme/billing-api
branch: epho/try-invoice-test-repair

task: |
  Fix the failing invoice service tests without changing public API behavior.

allowed_paths:
  - app/services/invoices/**
  - test/services/invoices/**

blocked_access:
  - production secrets
  - deploy commands
  - customer data exports
  - package publishing tokens

allowed_commands:
  - bundle exec ruby test/services/invoices
  - git diff -- app/services/invoices test/services/invoices

exit_condition: |
  Invoice service tests pass, and the returned artifact includes a patch plus test output.

artifacts_expected:
  - git diff
  - test log
  - command log
  - short summary of changed behavior

human_decision:
  - apply manually
  - ask for a narrower patch
  - discard

This receipt is intentionally small. The goal is not to design a grand policy; it is to make the first remote run auditable enough that you can tell whether the runner helped.

One methodology lens

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

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• How should teams start with Claude Code?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “Epho Runs Claude Code with Curl.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• Epho — source
• Claude Code — getting started
• Model Context Protocol — specification
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.