---
name: telegram-agent-migration
description: Ahmed is moving the interactive Telegram-connected Claude agent from the VPS to his own PC
metadata: 
  node_type: memory
  type: project
  originSessionId: e76b8acc-b39e-441c-ad82-68c4ed982296
---

On 2026-07-04 Ahmed decided to migrate the interactive "chat with Claude on Telegram" layer off
the VPS onto his own PC (explicitly chose losing 24/7 availability over keeping it VPS-only —
he wants a PC-based instance instead/in addition).

Mechanics of the current VPS setup (for whoever does this migration):
- The agent runs in a tmux session named `agent` on the VPS.
- `/root/tools/agent-watchdog.sh` (cron, every minute) relaunches it via `agent-launch.sh` if the
  tmux session ever dies; `@reboot` also launches it.
- Bot token lives at `/root/.claude/channels/telegram/.env` (`TELEGRAM_BOT_TOKEN`) — never paste
  its value into Telegram; he can read it himself via SSH or re-fetch it from @BotFather.
- To fully hand off: remove the two crontab lines (agent-watchdog.sh, agent-launch.sh) and
  `tmux kill-session -t agent`, then set up `/telegram:configure` on the PC with the same or a new
  bot token.

**Why:** His call — wants to try running the agent from his own machine. Related to
[[personal-device-control-nodes]] (same theme: extending/relocating agent access to his own gear).

**How to apply:** Ultron's actual scraping/enrichment pipeline (heartbeat, verify-run,
enrich-reviews, enrich-web, plan-manager, ops-watch, ops-digest cron jobs) is INDEPENDENT of this
agent tmux session — killing the agent does not stop the lead-gen pipeline, only the interactive
Telegram chat layer. Don't assume one implies the other. As of this memory, migration steps were
only given to him (not executed) — he was going to confirm his PC side works before asking to kill
the VPS-side tmux/cron. If a future session finds the VPS agent tmux gone/watchdog disabled,
that's expected outcome of this migration, not a bug.