cliclaw Runs Coding CLIs From Telegram

cliclaw is an open-source macOS daemon by Younggi Choi that lets you drive local coding CLIs from Telegram. It deals with a very specific itch: you want to check, steer, or restart a coding agent from your phone without opening a laptop or exposing a full remote shell. The takeaway is simple: this is a clever remote-control layer, but it should be treated like a thin command bridge with a tight safety boundary.

cliclaw is a Telegram bot that spawns authenticated local child processes for Claude Code, Anthropic's coding agent; Codex CLI, OpenAI's command-line coding agent; Pi, Earendil Works' coding agent; and Gemini CLI, Google's coding CLI. For Codex readers arriving through codex cli github searches, the important detail is that cliclaw does not replace OpenAI Codex; it wraps the local Codex CLI you already installed and logged into.

See the small trick before the big idea

The neat part of cliclaw is not that it adds another AI agent. It puts a chat surface in front of agents you already run locally.

The project keeps independent per-agent sessions for every Telegram chat. That means one chat can be talking to Codex while another is talking to Claude Code, without blending the conversation state. It also supports streamed responses, image attachments, automatic launchd installation on macOS, and detection for corporate TLS interception such as Zscaler.

As of August 2026, the repository is small: 7 GitHub stars, mainly TypeScript, MIT licensed, and last pushed on 2026-07-27. That matters. This is not a platform announcement. It is a Show HN-style utility that found a recognizable pain point and wrapped it in a surprisingly concrete workflow.

The trap is to see Telegram and assume toy. A phone chat can be a good control plane for status checks, small edits, and approvals. It is a bad place for vague prompts that can mutate a repo while you are half-watching from a train.

Why developers cared about the phone

The Hacker News reaction circled the practical question: what is this actually for? That is the right question.

The useful use case is not writing a whole feature from a phone. It is nudging a long-running local agent while your laptop is open somewhere else. Think: ask Codex to summarize the failing test, tell it to retry after you pushed a fix, or approve a generated migration only after you read the diff.

A concrete repo example: you leave a macOS dev machine running in a branch called fix-payment-webhook-timeout. Codex is investigating a flaky integration test. From Telegram, you ask for the current failure, request a one-file patch, and require it to run bun test test/webhook-timeout.test.ts before it reports back.

The trap is treating chat as a secure terminal emulator. Telegram is convenient, not magic. If Telegram is blocked on a network or in a country, cliclaw will not bypass that. If your company forbids source code or secrets in chat systems, this project does not make that policy disappear.

Put a hard boundary around dangerous actions

cliclaw's most important feature is the confirm gate for dangerous commands. That is the difference between remote supervision and remote regret.

A confirm gate is a pause before risky actions where the human must explicitly approve the command. In a coding-agent workflow, that usually means anything that deletes files, rewrites history, installs packages, touches credentials, runs deploy commands, or modifies production data.

For Codex workflows, pair the Telegram gate with repo-local instructions. Put the durable rule in AGENTS.md, not in a one-off chat message that will vanish into the session.

# AGENTS.md

Before changing files, explain the intended edit and list the files you expect to touch.

Never run destructive commands without explicit approval. This includes rm -rf, git reset --hard, git push --force, database migrations, deploy commands, and secret rotation.

After editing, run the narrowest verification command first. Prefer a single test file before a full suite.

That tiny file gives Codex a local operating contract. The Telegram confirm gate then becomes a second stop, not the only stop.

The trap is writing rules that sound safe but cannot be checked. Prefer named commands and named files. Be careful is vibes. Run bun test test/webhook-timeout.test.ts before reporting success is an instruction.

Try it when the task is narrow

cliclaw is worth trying when the work can be supervised in small, reversible steps. A good first task is a failing test, a docs correction, a small refactor, or an agent status query.

It is overkill when you are sitting at the machine, doing deep design work, or reviewing a security-sensitive change. It is also a poor fit if the repo has no fast verification loop. Phone control gets much worse when every answer is just still running for twenty minutes.

For Codex CLI workflows, the practical test is whether you can name the repo, branch, command, and stop condition before opening Telegram. The phrase codex cli github should lead you to the official CLI and repo, but your actual safety comes from local instructions, command gates, and reviewable diffs.

A clean starting command workflow looks like this:

npm install -g @openai/codex
codex
bun test test/webhook-timeout.test.ts
git diff --stat
git diff

If you use MCP, keep the boundary boring. Give the agent read-only access to issue trackers or docs first. Do not connect write-capable production systems to a phone-mediated workflow until you have logs, permissions, and a habit of reading the diff.

Try cliclaw safely

Use this as a small experiment, not a grand new way to code.

Copy this checklist before the first run:

• Install only the coding CLI you plan to test first, such as npm install -g @openai/codex.
• Use a throwaway branch, not main.
• Add or tighten AGENTS.md before starting the bot.
• Pick one verification command and write it down.
• Keep secrets, .env files, production dashboards, and deploy commands out of scope.
• Ask for git diff --stat before any full diff.
• Approve dangerous commands only when you understand why they are needed.
• Stop after one successful narrow task and review from your laptop.

There is a cousin idea here: supervising agents without staring at their terminal. If that is the part that interests you, the terminal-side version is explored in tmux-agent-switcher Watches Coding Agents.

Try one boring task first

Install one CLI, pick one branch, and ask cliclaw to supervise one small verification loop. If the diff is easy to review afterward, you have learned something useful without giving chat the keys to the repo.

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 Codex artifact first: an AGENTS.md instruction, a Codex CLI verification loop, an MCP boundary note, or a skills handoff.
- [ ] 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

• What should teams know about codex cli github?

  Start by writing down one visible team rule for Codex, 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 Codex artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a AGENTS.md instruction, MCP note, or verification checklist. 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: Codex teams deciding which AGENTS.md instruction, CLI workflow, MCP boundary, or verification loop to standardize next around “cliclaw Runs Coding CLIs From Telegram.”
• Best first artifact: turn the named fix into an AGENTS.md rule, verification checklist, MCP note, or review receipt before the next automated run.
• Best comparison angle: compare the workflow against the current Codex CLI review loop, shell boundary, and evidence trail; keep the path that leaves the shortest auditable trail.

Further reading

• cliclaw — source
• OpenAI Developers — Codex CLI
• GitHub — openai/codex
• OpenAI developers: codex quickstart

Next move

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.