In my last post on agentic workflows, I talked about workflow engineering — how the pipeline you design around AI matters more than the AI itself. I built a book inventory app that way. Skills, OpenSpecs, beads, parallel agents in tmux. It worked great.
But there was an asterisk I didn't mention: I was sitting at my desk the whole time.
What happens when you're not?
The Setup
Claude Code recently got a Telegram integration. The idea is simple: you control Claude Code from your phone through a Telegram bot. Same skills, same workflow, same project — different interface. If you've used the plugin system at all, setup is straightforward. Documentation walks you through it, you're chatting with your agent in minutes.
In fact, as of today, Anthropic officially shipped this as Claude Code Channels — a plugin-based feature that lets you push messages from Telegram or Discord into a running Claude Code session on your machine. Your session processes the request with full filesystem, MCP, and git access, then replies through the same chat. It's built on MCP, which means it slots into the existing plugin ecosystem cleanly. I ran my experiment the day it launched, so what you're reading is a day-one field report.
I wanted to test this properly, so I gave it a real task. Not a toy. A refactoring sessions on an existing codebase, the kind of thing I'd normally spend a focused afternoon on. Except today, I wasn't at my desk and I wasn't focused. I was doing something else, checking Telegram between other things.
Buckle up.
The Permission Wall
Immediately: a wall.
Claude Code has a permission system. It asks before it does anything potentially destructive — file writes, shell commands, external calls. At your desk, this is fine. You see the prompt, you approve, you move on.
From Telegram? The bot doesn't forward those permission prompts. Your agent hits a permission check, and it just... stops - silently. You're staring at Telegram wondering why nothing is happening, and the answer is that Claude is staring at your terminal wondering why you're not approving anything.
This is the first thing you'll hit, and there's no elegant workaround. Either you solve the permission problem or you don't use this workflow.
The Context Ceiling
Second problem: context. Opus ships with a 1M token context window, which sounds like a lot. And it is — for a focused session. But "entire day, away from your machine, no way to reset" is a different budget. You can't /clear the session from Telegram. If the conversation gets heavy, you can't start fresh. You're stuck with whatever context you've accumulated.
For a day of casual back-and-forth this turned out to be manageable. But it's something you have to plan around, not something you can ignore.
Biting the Bullet
So I did the thing you're not supposed to do: --dangerously-skip-permissions.
I know. The flag name exists for a reason. But here's my reasoning: I wasn't installing new external dependencies. My Claude Code workflow is already scoped — skills are loaded, the project is defined, the agent knows its boundaries.
And it worked. The permission wall disappeared. The agent could actually run.
Not great, not terrible. I'm still not comfortable disabling guardrails as a general practice. For this specific experiment, with this specific setup, it was a calculated risk. Use at your own discretion. Or better — don't. Anyway, don't blame me if Claude decides your main branch needs to have a different history and you don't have branch protection in place. You've been warned.
Saving Context With Agent Teams
The context problem needed a different solution. If I can't clear the session, I need to use less of it.
This is where the workflow from my previous post paid off. If you haven't read it: I use a pipeline where work gets decomposed into beads — small, focused tasks based on Steve Yegge's beads concept. Each bead is scoped tightly enough that a sub-agent can pick it up and run with it without needing the full conversation history.
So I instructed the main agent to delegate aggressively. The pipeline looked like this:
- I describe what I want via Telegram
- Main agent runs a spec creator sub-agent which generates an OpenSpec (a structured definition of the change) and makes a draft PR on GitHub
- I review the spec from my phone and approve
- Spec gets decomposed into beads
- Sub-agents pick up beads, implement, commit, and update the PR
The main session barely touched any implementation detail. It just coordinated. By the end of the day, I'd used about 30% of the context window. Granted, I wasn't going crazy with requests — but the pattern held up.
Why Not Claude Code on the Web?
Fair question. Claude Code has a web interface now. I could've used that from my phone. No Telegram bot, no permission hacks.
The answer is boring: my tools. My skills are loaded locally. My workflow is configured. I have Playwright set up for visual verification — I literally had the agent screenshot pages to confirm layout changes actually landed. That's not something you get from the web interface.
When you've invested in a workshop, you want to use it. Even from a distance.
The Slow Loop
Here's the real downside, and it's not about permissions or context.
The feedback loop is slow.
At my desk, I have hot reload. I change something, I see it instantly. From Telegram, the loop is: agent pushes to GitHub → Vercel builds a preview → I check the preview on my phone. That's minutes, not milliseconds. For layout work especially, it's painful. You're doing the development equivalent of texting someone in the next room instead of just talking to them.
I could live with it because I was mostly multitasking — checking in on the agent between other things. But if this were my primary way of working? The latency would get to me.
The Numbers
I had Claude Code analyze the session after the fact and here's what a day of remote agent work actually looks like:
Overview
| Metric | Value |
|---|---|
| Total tool calls | 507 |
| Agents spawned | 22 across 5 teams |
| PRs created / merged | 5 / 5 |
| Telegram messages | 34 |
| Playwright interactions | 50 |
| OpenSpec tasks verified | 76 |
Agents
| Role | Count |
|---|---|
| QA | 4 |
| Spec Writer | 3 |
| Frontend | 3 |
| Explorer | 3 |
| Backend | 1 |
| Reviewers | 3 |
| Standalone | 9 |
Features
| Feature | Status |
|---|---|
| Crop inset fix | merged |
| Remove impressum crop | merged |
| Scrollable mapping | merged |
| Reading status | in review |
| OpenSpec cleanup (3 lists) | 76 tasks |
507 tool calls, 22 agents, 34 Telegram messages, 5 PRs. From my phone.
The Verdict
At the end of the day, I sat down and did what I always do: reviewed the code myself. Read every change, checked every decision. And it was fine. A few minor optimizations I would've caught in real-time at my desk, but nothing structural. Nothing that made me regret the experiment.
So here's the honest scorecard:
What works: Your full workflow, from Telegram. Skills, beads, agent teams, even Playwright screenshots. If you've built a good pipeline, it travels.
What doesn't: Permission prompts don't reach you. Context can't be reset. The feedback loop trades seconds for minutes. And you'll probably end up running with --dangerously-skip-permissions, which is exactly as comfortable as it sounds.
Who is this for: Someone who's already set up their Claude Code workflow and wants to keep things moving while away from their desk. Not as a primary dev environment — as an extension of one you already trust.
Would I do it again? Yeah, probably. But I'd plan the work differently. Bigger, well-defined refactorings that don't need rapid visual feedback. The kind of work where you can fire and forget, then review later. Not pixel-pushing. Not exploratory coding. Structured changes through a structured pipeline.
Remote slop? A little. But manageable slop, with a review step at the end. And sometimes that's enough.
Top comments (0)