I wanted one agent workspace I could reach from a laptop or phone while the actual files and tools stayed on a machine I controlled. Anthropic's current Claude Code Channels documentation describes the preview integrations, per-session behavior, and authentication requirements. Channels can be part of that design, but the useful architecture is broader than one integration.
It has four parts: an always-on host, selectively synchronized context, an authenticated message channel, and a restart path you have tested.
Why use two machines
My laptop is where I work. A Mac Mini can be the stable host for scheduled or remote tasks. The host stays awake, keeps the approved repositories and tools available, and avoids tying the workflow to whether my laptop lid is open.
That does not make the Mini a trusted execution environment by magic. It still needs disk encryption, operating-system updates, scoped credentials, logging, and a way to disable access quickly.
Sync less than you think
The temptation is to mirror the entire home directory. I do not.
I sync selected project knowledge, reusable instructions, and approved configuration. I exclude secrets, caches, dependency directories, runtime sockets, databases, logs, and machine-specific state. Git repositories usually move through Git; sensitive credentials move through an approved secrets system, not folder sync.
For each shared path, decide which machine is authoritative. Two-way sync of rapidly changing state can create conflicts that look like valid files to an agent.
Treat the channel as a control surface
A Telegram or other message channel is convenient because it reaches the host. It is also a remote control surface.
I require an allowlist of sender identities, separate read-only commands from state-changing commands, and force consequential actions through an approval step. The channel should never accept arbitrary shell instructions from anyone who can reach the bot.
Untrusted messages and linked content can carry prompt injection. The agent must not expand permissions because a message asks nicely.
Current setup, current docs
Channel installation commands, supported messaging services, and process behavior are version-sensitive. Follow the current official Claude Code Channels documentation for the integration you use. Verify the installed version and run a local, read-only test before enabling remote access.
Then test this sequence:
- send an authenticated health request;
- read a harmless file from an approved directory;
- reject a request outside that directory;
- require approval for a write;
- restart the host process and repeat the tests.
Make recovery boring
An always-on workflow needs a supervisor, but the exact LaunchAgent file from an old tutorial is not durable guidance. Create the service definition from the current binary path and environment. Keep secrets out of the plist. Capture standard output and errors in a protected location. Add bounded restart behavior so a crash loop does not burn money forever.
The health check should prove more than “process exists.” It should prove the right version is running, the channel is authenticated, the approved workspace is reachable, and a known read-only request succeeds.
The decision boundary
Use this architecture when local files or tools genuinely require an always-on machine. If the task can run safely in a supported cloud environment with narrower access, the extra host may be unnecessary.
The goal is not to replace one agent brand with another. It is to create a reachable operator whose identity, files, tools, and restart behavior you can explain. If you cannot describe that boundary, do not put it behind a chat app yet.