Claude Remote Control vs Cowork vs Slack vs Telegram/Discord/OpenClaw — Research-Grade Guide, Playbook, and AI Handoff (2026-03-17)

Executive Summary

This document extracts, verifies, corrects, and improves the key findings from the discussion about how to access Claude from remote/mobile surfaces while still working with local files, local repos, or local Claude sessions.

Bottom line:

  • [Verified] If the goal is “use the cloud/web interface while operating on local files on your own machine”, the official Anthropic feature is Claude Code Remote Control. Remote Control runs on your machine, exposes the session to claude.ai/code and the Claude mobile app, keeps local filesystem / local tools / local MCP servers available, uses outbound HTTPS only, and does not open inbound ports. It is distinct from Claude Code on the web, which runs in Anthropic-managed cloud infrastructure. [Ref 1][Ref 2]
  • [Verified] Cowork is still primarily a desktop-runner feature, but the discussion needed an important correction: as of March 17, 2026, Anthropic now has a research-preview “Dispatch” / persistent thread model that lets Pro/Max users message Cowork from mobile while work still happens on the desktop machine. This does not make Cowork a normal cloud-synced web surface; the desktop app still must remain open and the computer must stay awake. [Ref 3][Ref 4][Ref 5]
  • [Verified] If the goal is official messaging-native access, the strongest clean option is Claude in Slack / Claude Code in Slack, but it has real limitations: coding tasks route to Claude Code on the web, not your local machine; current limitations include GitHub-only, one PR per session, plan rate limits, and several Slack-surface limits such as no Research, no Extended thinking, and no creating new integrations from within Slack. [Ref 6][Ref 7][Ref 8][Ref 9]
  • [Verified] Anthropic’s current Claude Code legal/compliance docs explicitly state that OAuth authentication from Claude Free/Pro/Max is intended exclusively for Claude Code and Claude.ai, and using those credentials in other products, tools, or services is not permitted. That materially changes the risk profile for unofficial “use my Claude subscription in Telegram/Discord/OpenClaw” patterns. [Ref 10]
  • [Assistant-stated but unverified] The current public GitHub ecosystem strongly suggests that the most active unofficial path is thin Telegram/Discord bridges to local Claude Code sessions, not “true official-quality subscription-backed multi-channel Claude clones.” Several repos advertise persistent local session bridges, approvals, notifications, or rich messaging UX. These claims come primarily from repository READMEs and were not independently tested in this research pass. [Ref 11][Ref 12][Ref 13][Ref 14]
  • [Verified + Assistant-stated but unverified] OpenClaw is a real and active multi-channel personal-assistant project, but its own docs repeatedly warn that Anthropic setup-token / subscription auth is technical compatibility only, not a policy guarantee, and current GitHub issues show recurring 401 invalid bearer token problems with Anthropic OAuth/setup-token usage. OpenClaw’s docs themselves recommend treating API-key auth as the safer path. [Ref 15][Ref 16][Ref 17][Ref 18][Ref 19]

Purpose of This Document

This artifact is designed to serve as all of the following:

  • a guide for deciding which Claude access pattern to use,
  • a playbook for implementation and evaluation,
  • a briefing memo for strategic/tooling decisions,
  • and a handoff document for another AI so work can continue without re-reading the original chat.

The document does not assume that earlier assistant claims were correct. It re-checks the important claims against current official documentation and current public project pages/issues where available.

Discussion Context

User goals and constraints

  • [User-stated] The user wants a way to work with local files using a cloud/mobile interface, ideally without being locked into a desktop-only experience.
  • [User-stated] The user is specifically interested in alternatives to Remote Control that feel more like OpenClaw / Telegram / Discord / “talk to Claude from anywhere”.
  • [User-stated] The user cares about whether these options can work with a Claude subscription model, not only via API usage.
  • [User-stated] The user wants current, up-to-date guidance, with attention to real-world nuance rather than stale assumptions.
  • [User-stated] The user values smart-cut approaches, operational leverage, and tooling that can fit an AI-native workflow.
  • [User-stated] The user uses Windows + WSL heavily and is likely to care about setup friction, browser limitations, and local-dev ergonomics.

Scope of this research artifact

This document focuses on:

  1. official Anthropic paths for remote/mobile/cloud access,
  2. official Slack/Cowork/Remote Control distinctions,
  3. unofficial Telegram/Discord/OpenClaw approaches,
  4. policy and support boundaries,
  5. practical tradeoffs for a founder/operator/dev workflow.

It does not include a full install guide for any one unofficial project; those should be produced in a follow-up once a path is chosen.

Key Facts and Verified Findings

1) Official Anthropic product surfaces

1.1 Claude Code Remote Control

  • [Verified] Remote Control is the official Anthropic feature for continuing a local Claude Code session from a phone, tablet, or browser using claude.ai/code or the Claude mobile app. [Ref 1]

  • [Verified] Remote Control sessions run directly on your machine and interact with your local filesystem. Anthropic explicitly contrasts this with Claude Code on the web, which runs on cloud infrastructure. [Ref 1]

  • [Verified] Remote Control requires Claude Code v2.1.51 or later. [Ref 1]

  • [Verified] The recommended interactive command pattern is:

    claude --remote-control "My Project"

    Anthropic says this gives you a full interactive local session that you can also control from claude.ai or the Claude app. [Ref 1]

  • [Verified] claude remote-control is server mode, which waits for remote connections and supports flags such as --name, --spawn, --capacity, and optionally --sandbox / --no-sandbox. Anthropic states sandboxing is off by default in server mode. [Ref 1]

  • [Verified] Remote Control can be enabled for every interactive session through /config. Each interactive Claude Code process registers one remote session. [Ref 1]

  • [Verified] Remote Control uses outbound HTTPS only and does not open inbound ports. Anthropic says the session registers with the Anthropic API and traffic flows over TLS. [Ref 1]

  • [Verified] Remote Control keeps local MCP servers, tools, and project configuration available because the session is still running locally. [Ref 1]

  • [Verified] Key limitations:

    • one remote session per interactive process outside server mode,
    • the terminal/process must stay open,
    • if the machine cannot reach the network for roughly 10 minutes, the session times out and exits. [Ref 1]
  • [Verified] The current changelog shows Claude Code 2.1.78 on March 17, 2026, and the changelog includes recent Remote Control-related fixes and rollout milestones. [Ref 20]

1.2 Claude Code on the web (--remote)

  • [Verified] Claude Code on the web is a different product surface. Anthropic describes it as running Claude Code tasks asynchronously on secure cloud infrastructure. [Ref 2]
  • [Verified] When a web session starts, Anthropic says the repository is cloned into an Anthropic-managed virtual machine. [Ref 2]
  • [Verified] Anthropic explicitly states that if you want the web interface while running Claude Code on your own machine instead of cloud infrastructure, you should use Remote Control. [Ref 2]
  • [Verified] Session handoff is one-way: you can pull web sessions into your terminal, but you cannot push an existing terminal session to the web. claude --remote creates a new web session. [Ref 2]
  • [Verified] Current platform limitation: Claude Code on the web works only with GitHub-hosted code. [Ref 2]

1.3 Cowork

  • [Verified] Cowork is Anthropic’s agentic work mode inside Claude Desktop. Anthropic says it uses the same agentic architecture that powers Claude Code, but it is surfaced in the desktop app rather than the terminal. [Ref 3]
  • [Verified] Current Help Center docs say Cowork requires the desktop app and is not available on web or mobile as a standalone surface. [Ref 3]
  • [Verified] The Claude Desktop app must remain open while Cowork is working, and the computer must remain awake; otherwise active work stops. [Ref 3]
  • [Verified] Cowork currently offers scheduled tasks, and scheduled tasks only run while the computer is awake and Claude Desktop is open. [Ref 5]
  • [Verified] Cowork currently supports plugins, and Anthropic says Cowork plugins bundle skills, connectors, and sub-agents. [Ref 21]
  • [Verified] Important current limitations in Help Center docs include:
    • no memory across sessions,
    • no chat or artifact sharing,
    • desktop app required,
    • session persistence depends on the app staying open and the computer remaining awake. [Ref 3]

1.4 New March 17, 2026 Cowork mobile/Dispatch update

  • [Verified] This discussion required a material correction because Anthropic launched a new Cowork mobile capability on March 17, 2026. Release notes say Pro and Max users can now access a persistent agent thread via Claude Desktop or Claude for iOS/Android to manage tasks in Cowork. [Ref 4]
  • [Verified] Anthropic’s new “Assign tasks to Claude from anywhere in Cowork” page states that Cowork now gives you one continuous conversation reachable from phone or desktop; Claude runs on your computer with access to your local files, connectors, and plugins, and messages you the result when done. [Ref 5]
  • [Verified] This is a research preview, rolling out gradually to Max plans first and Pro plans next. [Ref 4][Ref 5]
  • [Verified] Requirements include:
    • latest Claude Desktop app installed and running,
    • latest Claude mobile app,
    • Pro or Max plan,
    • active internet on both devices. [Ref 5]
  • [Verified] Current limitations of this new Cowork mobile thread:
    • desktop must remain active,
    • Claude only responds to user messages and does not proactively reach out,
    • one continuous thread only,
    • no completion notifications yet,
    • scheduled tasks are managed separately. [Ref 5]

Interpretation:

  • [Verified] Earlier “Cowork is desktop-only” statements are now partially outdated if interpreted too broadly.
  • [Verified] Cowork is still desktop-executed and desktop-dependent, but now there is a phone/desktop persistent thread for Pro/Max users in research preview. [Ref 4][Ref 5]

2) Official Slack surfaces

2.1 “Claude in Slack” / “Claude Code in Slack”

  • [Verified] Anthropic’s Slack docs distinguish between using Claude in Slack generally and routing coding tasks from Slack to Claude Code on the web. [Ref 6][Ref 7]
  • [Verified] For Claude Code in Slack, Anthropic says:
    • the Claude app must be installed in the Slack workspace,
    • a Claude Owner or Primary Owner must enable Claude Code on the web,
    • the user must have Claude Code on the web access,
    • repository selection is based on repositories authenticated to Claude Code on the web. [Ref 7][Ref 8]
  • [Verified] Claude Code in Slack session flow:
    1. user @mentions Claude with a coding request,
    2. Claude detects coding intent,
    3. a new Claude Code session is created on claude.ai/code,
    4. Claude posts progress updates in the Slack thread,
    5. Claude finishes with a summary and action buttons,
    6. user can click to view the full transcript or create a PR. [Ref 6]
  • [Verified] Anthropic says that in Slack you mainly see status updates, completion summaries, and action buttons, while the web view contains the full conversation history, code changes, file operations, and the ability to continue the session or create PRs. [Ref 6]
  • [Verified] Anthropic recommends Slack when:
    • context already exists in a Slack thread,
    • you want to kick off a task asynchronously,
    • teammates need visibility. [Ref 6]
  • [Verified] Anthropic recommends the web instead when:
    • you need file uploads,
    • you want real-time interaction during development,
    • you are working on longer, more complex tasks. [Ref 6]

2.2 Current limitations of Claude Code in Slack

  • [Verified] Current limitations documented by Anthropic:
    • GitHub only,
    • one PR at a time per session,
    • rate limits apply using the individual user’s plan,
    • web access required. [Ref 8]
  • [Verified] Slack workspace/channel access is governed by:
    • workspace admins installing/removing the app,
    • users explicitly inviting Claude into channels,
    • channel-based access gating. [Ref 6]

2.3 General “Using Claude in Slack” limitations

  • [Verified] Anthropic’s Help Center states that the following are not available when using Claude in Slack:
    • Research
    • Extended thinking
    • creating new integration connections from within Slack
      Existing integrations already connected in Claude settings can still work. [Ref 9]

2.4 Slack connector vs Slack docs discrepancy

  • [Verified] There is a documentation conflict on plan availability for the Slack connector:
    • the connector docs at claude.com/docs/connectors/slack say the Slack connector is available for Team and Enterprise plans, [Ref 22]
    • while the Help Center article “Getting started with Claude in Slack” says the Slack connector is available for all paid plans (Pro, Max, Team, Enterprise). [Ref 23]

This discrepancy should be treated as unresolved until tested in the target account or clarified by Anthropic.

3) Official guidance on local setup enhancements

3.1 CLAUDE.md and memory

  • [Verified] Anthropic’s current docs say Claude Code has two memory mechanisms:
    • CLAUDE.md files you write,
    • auto memory that Claude writes itself. [Ref 24]
  • [Verified] CLAUDE.md is context, not hard enforcement. Anthropic explicitly says Claude treats it as context, not enforced configuration. [Ref 24]
  • [Verified] Project CLAUDE.md locations include:
    • ./CLAUDE.md
    • ./.claude/CLAUDE.md [Ref 24]
  • [Verified] Anthropic says /init can generate a starting CLAUDE.md automatically. [Ref 24]

3.2 Permissions

  • [Verified] Anthropic’s permission rules evaluate in the order deny ask allow, with deny taking precedence. [Ref 25]
  • [Verified] Permission modes include default, acceptEdits, plan, dontAsk, and bypassPermissions. [Ref 25]
  • [Verified] Anthropic warns that bypassPermissions should only be used in isolated environments like containers/VMs. [Ref 25]

3.3 MCP

  • [Verified] Anthropic documents three major MCP scopes:
    • local
    • project
    • user [Ref 26]
  • [Verified] Anthropic notes that on native Windows (not WSL), local MCP servers using npx require the cmd /c wrapper. [Ref 26]

3.4 Plugins

  • [Verified] Claude Code plugins can extend Claude Code with skills, agents, hooks, and MCP servers. [Ref 27]
  • [Verified] Installation scopes for plugins include user, project, and local. [Ref 27]
  • [Verified] Anthropic warns that plugins and marketplaces are highly trusted and can execute arbitrary code on the machine with user privileges. [Ref 27]

3.5 Chrome integration and WSL caveat

  • [Verified] Anthropic’s current Chrome integration beta works with Google Chrome and Microsoft Edge, and is not supported on Brave, Arc, or WSL. [Ref 28]
  • [Verified] Claude Code + Chrome can be used for build-test-debug workflows, but login pages/CAPTCHAs still require manual intervention. [Ref 28]

3.6 VS Code

  • [Verified] Anthropic says the VS Code extension is the recommended way to use Claude Code in VS Code. [Ref 29]

4) Policy and support boundary for subscription-based third-party messaging bridges

4.1 Anthropic official policy

  • [Verified] Anthropic’s legal/compliance doc states:
    • OAuth authentication used with Free/Pro/Max is intended exclusively for Claude Code and Claude.ai,
    • using those OAuth tokens in any other product, tool, or service — including the Agent SDK — is not permitted. [Ref 10]

This is one of the most important facts in the entire discussion.

4.2 Why this matters

  • [Verified] Any third-party Telegram/Discord/OpenClaw-style bridge that depends on reusing Claude subscription OAuth/setup-token credentials outside Claude Code / Claude.ai carries at least:
    • policy risk,
    • possible breakage risk,
    • supportability risk. [Ref 10][Ref 15][Ref 16]

5) Community ecosystem snapshot (public GitHub/docs, not runtime-tested)

5.1 Lightweight Telegram bridge to local Claude Code

  • [Assistant-stated but unverified] terranc/claude-telegram-bot-bridge claims to be a lightweight Telegram bot that bridges Claude Code to a local folder with autostart support. The README claims:
    • “lightweight, zero-infrastructure, secure by default,”
    • persistent always-on Claude Code session,
    • no web server / no exposed ports / no extra auth layer,
    • remote skill and slash-command invocation,
    • model switching,
    • session resume and history. [Ref 11]

This appears to be a strong candidate for a private, low-infrastructure personal bridge, but the claims were not independently validated.

5.2 Richer Telegram bot

  • [Assistant-stated but unverified] linuz90/claude-telegram-bot claims to turn Claude Code into a personal assistant over Telegram and supports:
    • text,
    • voice,
    • photos,
    • documents,
    • audio,
    • video,
    • real-time response/tool display. [Ref 12]

Again, these are README claims, not tested findings.

5.3 Telegram bot with session persistence / notifications / sandboxing

  • [Assistant-stated but unverified] RichardAtCT/claude-code-telegram claims:
    • automatic session persistence per project,
    • Telegram access from any device,
    • webhook / scheduled job / CI-CD notifications,
    • built-in authentication,
    • directory sandboxing,
    • audit logging. [Ref 13]

This appears stronger for more operational/dev workflows, but remains untested here.

5.4 Discord controller / multi-machine hub

  • [Assistant-stated but unverified] chadingTV/claudecode-discord claims:
    • multi-machine agent hub via Discord,
    • “No API key needed — works with your existing Claude Pro or Max subscription,”
    • daemon mode,
    • starting new sessions from phone,
    • one Discord channel per project directory,
    • approve/deny buttons,
    • message queueing,
    • usage dashboard,
    • zero open ports,
    • Windows/macOS/Linux system tray or menu bar support. [Ref 14]

This project is notable and recent, but the specific claim that it works with the user’s Claude Pro/Max subscription should be treated as high policy risk relative to Anthropic’s official OAuth-use policy. [Ref 10][Ref 14]

5.5 OpenClaw

  • [Verified] The official OpenClaw repo describes OpenClaw as a personal AI assistant run on your own devices, supporting many channels including WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage, Teams, Matrix, and more. [Ref 30]
  • [Verified] OpenClaw’s docs say its onboarding can configure Anthropic using either API key or claude setup-token. [Ref 16]
  • [Verified] OpenClaw’s docs explicitly warn that Anthropic setup-token/subscription auth is technical compatibility, not a policy guarantee, and that Anthropic has blocked some subscription usage outside Claude Code in the past. [Ref 15][Ref 16][Ref 17]
  • [Verified] OpenClaw’s docs also explicitly say that if Anthropic returns the error “This credential is only authorized for use with Claude Code and cannot be used for other API requests,” the user should use an Anthropic API key instead. [Ref 15]
  • [Verified] Recent OpenClaw GitHub issues show ongoing problems with Anthropic setup-token/OAuth auth, including:
    • 401 invalid bearer token issues,
    • regressions tied to context-1m headers / OAuth interactions,
    • suggestions to fall back to standard Anthropic API keys. [Ref 18][Ref 19][Ref 31]

Major Decisions and Conclusions

Decision 1: Do not treat “Cowork,” “Remote Control,” and “Claude Code on the web” as interchangeable

  • [Verified] They may look similar from a user perspective, but Anthropic’s docs show they are meaningfully different product surfaces with different execution environments and limitations. [Ref 1][Ref 2][Ref 3][Ref 5]

Decision 2: If the requirement is “browser/mobile surface + my local repos/tools/files,” official path = Remote Control

  • [Verified] Remote Control is the official solution for this exact requirement. [Ref 1]
  • [Assistant conclusion derived from verified facts] This remains the cleanest official answer for coding/local-repo work despite the user’s dissatisfaction with its ergonomics.

Decision 3: If the requirement is “phone-based operational tasking against desktop files/tools” and not necessarily coding, Cowork Dispatch is now a serious official option

  • [Verified] As of March 17, 2026, Cowork now supports a persistent mobile/desktop thread in research preview for Pro/Max. [Ref 4][Ref 5]
  • [Assistant conclusion derived from verified facts] This is important because it partially fills the gap that earlier users might have tried to solve via OpenClaw-like flows.

Decision 4: If the requirement is “official messaging-native access,” Slack is the clean path, but it is more limited than community bridges

  • [Verified] Slack is more governed and supported, but weaker for local-machine control and richer personal-assistant behavior. [Ref 6][Ref 7][Ref 8][Ref 9]

Decision 5: Treat third-party “use my Claude subscription via Telegram/Discord/OpenClaw” paths as policy-risky and brittle

  • [Verified] Anthropic’s OAuth policy language is explicit. [Ref 10]
  • [Verified] OpenClaw’s own docs and issues reinforce the fragility of Anthropic subscription-auth outside official surfaces. [Ref 15][Ref 16][Ref 17][Ref 18][Ref 19]

Reasoning, Tradeoffs, and Why It Matters

Comparison matrix

OptionEvidence statusExecution locationAccess to local files/toolsMessaging-native UXOfficially supportedMain limitations / risks
Claude Code Remote ControlVerifiedYour machineYesModerate (web/mobile surface)YesTerminal must stay open; one remote session per interactive process; not as “chat-app-native” as Telegram/Discord [Ref 1]
Claude Code on the webVerifiedAnthropic cloud VMNo (local), yes for cloned GitHub repoModerateYesGitHub-only; new cloud session; not local machine [Ref 2]
Cowork desktopVerifiedYour machine / desktop appYesLow by itselfYesDesktop app must stay open; not a normal web surface [Ref 3]
Cowork Dispatch persistent mobile threadVerifiedYour desktop machineYesHigh (phone + desktop persistent thread)Yes, but research previewPro/Max rollout; one thread only; no proactive notifications; desktop must stay active [Ref 4][Ref 5]
Claude in Slack / Claude Code in SlackVerifiedSlack surface + Claude Code on webLimited / cloud-web orientedHigh in SlackYesGitHub-only for coding, one PR per session, Slack feature limits, weaker for local machine control [Ref 6][Ref 7][Ref 8][Ref 9]
Telegram bridge to local Claude CodeAssistant-stated but unverifiedUsually your machineUsually yesHighNoFeature claims untested; policy/support risk if subscription auth involved [Ref 11][Ref 12][Ref 13]
Discord Claude Code controllerAssistant-stated but unverifiedUsually your machineUsually yesHighNoSame risks as above; subscription-auth claim conflicts with Anthropic policy posture [Ref 10][Ref 14]
OpenClaw with Anthropic API keyVerified + assistant inferenceYour machine / gateway hostDepends on integrationVery highOpenClaw supported by itself; Anthropic API is officialMore setup complexity; ongoing ops burden; token-cost model rather than “free ride” subscription [Ref 15][Ref 16][Ref 30]
OpenClaw with Anthropic setup-token/subscription authVerified high riskYour machine / gateway hostDependsVery highNot cleanly supported by AnthropicPolicy risk + real 401/auth fragility in recent issues [Ref 10][Ref 15][Ref 16][Ref 18][Ref 19]

Why this matters for the user’s environment

  • [User-stated] The user wants something friendlier than Remote Control.
  • [Verified] The official landscape now has two separate alternatives that were easy to overlook:
    1. Cowork Dispatch for persistent phone-to-desktop tasking, [Ref 5]
    2. Slack for team-visible messaging-native workflows. [Ref 6][Ref 7]
  • [Assistant conclusion derived from verified facts] If the user’s core pain is “I want to message Claude from my phone and have it use my desktop environment,” Cowork Dispatch may now be a more relevant official feature than earlier discussion suggested.
  • [Assistant conclusion derived from verified facts] If the user’s core pain is “I want a true multi-session, push-notification, chat-app control plane for multiple repos/machines,” the community Discord/Telegram projects may be functionally closer — but they are not the safe/official lane.

Playbook A — Lowest-risk official path for local coding

Use when: the priority is working against local repos/files/tools from another device.

  1. [Verified] Install/update Claude Code to current version and verify claude --version. [Ref 1][Ref 20]

  2. [Verified] Add or refine project CLAUDE.md; use /init if needed. [Ref 24]

  3. [Verified] Configure /permissions conservatively; start in default or plan mode and add explicit deny rules where needed. [Ref 25]

  4. [Verified] Start interactive Remote Control:

    claude --remote-control "project-name"

    [Ref 1]

  5. [Verified] Open the session in claude.ai/code or the Claude app via session list / URL / QR. [Ref 1]

  6. [Verified] Only add plugins or MCP servers you trust. [Ref 26][Ref 27]

  7. [Verified] If browser automation matters, prefer Chrome or Edge and do not assume WSL support for Anthropic’s Chrome beta integration. [Ref 28]

Playbook B — Lowest-risk official path for “message Claude from phone, desktop does the work”

Use when: the priority is operational tasks, desktop file access, or messaging convenience from phone.

  1. [Verified] Confirm the account is on Pro or Max and the rollout is available. [Ref 4][Ref 5]
  2. [Verified] Update Claude Desktop and the Claude mobile app. [Ref 5]
  3. [Verified] Enable Cowork Dispatch / persistent thread. [Ref 5]
  4. [Verified] Audit Cowork access before enabling:
    • local files,
    • connectors,
    • plugins,
    • browser automation,
    • anything sensitive that should not be reachable from a mobile-triggered workflow. [Ref 5]
  5. [Verified] Use it only for tasks where one persistent thread is acceptable, and accept that the desktop must remain awake/open. [Ref 5]

Playbook C — Official team-facing async coding in messaging

Use when: the priority is channel visibility, team collaboration, or kicking off coding tasks from Slack.

  1. [Verified] Install Claude in Slack and connect Claude account(s). [Ref 7][Ref 8]
  2. [Verified] Ensure Claude Code on the web is enabled and users have access. [Ref 7][Ref 8]
  3. [Verified] Connect the GitHub repositories in Claude Code on the web. [Ref 2][Ref 6][Ref 7]
  4. [Verified] Use Slack for issue triage, async task kickoff, and teammate visibility. [Ref 6]
  5. [Verified] Route deeper interactive work back to the web because Slack is not the full control surface. [Ref 6]
  6. [Verified] Do not assume Research or Extended thinking will be available in Slack. [Ref 9]

Playbook D — Controlled pilot of a third-party Telegram/Discord bridge

Use when: the user explicitly wants richer mobile/chat-app control and accepts gray-area risk.

  1. [Assistant recommendation] Start on a non-production machine or isolated workspace.
  2. [Verified] Do not confuse “works technically” with “supported by Anthropic policy.” [Ref 10]
  3. [Assistant recommendation] Prefer a project that:
    • does not expose inbound ports,
    • offers approval controls,
    • supports path restrictions / sandboxing / allowlists,
    • persists sessions cleanly,
    • has recent activity. [Ref 11][Ref 13][Ref 14]
  4. [Assistant recommendation] Keep the blast radius small:
    • dedicate a machine or user account,
    • do not mount sensitive directories,
    • disable dangerous auto-approve,
    • use explicit whitelists,
    • log actions if the project supports it.
  5. [Assistant recommendation] Treat subscription-auth usage as temporary/fragile unless the project is reworked to use official API-key auth.
  6. [Assistant recommendation] Prefer a thin local bridge over a giant full-agent stack if the immediate goal is just “message my local Claude session from my phone.”

Playbook E — If choosing OpenClaw

Use when: the requirement is true always-on, multi-channel assistant behavior and the user is willing to self-host more infrastructure.

  1. [Verified] Use Anthropic API-key auth as the default expectation, not setup-token auth. [Ref 15][Ref 16][Ref 17]
  2. [Verified] Expect Anthropic setup-token/subscription auth to be fragile and policy-sensitive. [Ref 10][Ref 15][Ref 16][Ref 18][Ref 19]
  3. [Assistant recommendation] Run OpenClaw only after deciding:
    • which messaging channels truly matter,
    • which integrations are worth the risk,
    • what data can live on the gateway host,
    • how you will monitor auth failures and unexpected actions.
  4. [Verified] OpenClaw includes DM pairing and allowlist security defaults for many channels; use them rather than opening DMs broadly. [Ref 30]

Official Anthropic resources

Community / open-source resources

Risks, Caveats, and Red Flags

Official-surface caveats

  • [Verified] Cowork is moving quickly. Earlier assumptions may already be stale, especially around mobile access. [Ref 3][Ref 4][Ref 5]
  • [Verified] Slack docs currently disagree on connector plan availability. [Ref 22][Ref 23]
  • [Verified] Slack is not the full coding surface. Anthropic explicitly pushes longer/more complex work back to the web. [Ref 6]
  • [Verified] Chrome integration is not supported on WSL. [Ref 28]

Policy / support caveats

  • [Verified] Anthropic policy sharply limits reuse of Free/Pro/Max OAuth credentials outside Claude Code / Claude.ai. [Ref 10]
  • [Verified] Even where community tools claim “no API key needed,” that does not mean the pattern is officially allowed or durable. [Ref 10][Ref 14]

Community-project caveats

  • [Assistant-stated but unverified] Community repo READMEs often overstate ease or stability relative to real-world operation.
  • [Verified] OpenClaw’s own docs/issues indicate Anthropic subscription-auth can be fragile. [Ref 15][Ref 16][Ref 17][Ref 18][Ref 19]
  • [Assistant recommendation] Security posture matters more than convenience for any bot that can read files, run commands, browse, or touch connected services.

Strategy caveats

  • [Assistant conclusion] There is a temptation to over-optimize for “use my subscription everywhere.” That may save short-term API cost but can create a brittle and non-compliant workflow.
  • [Assistant conclusion] The right decision depends on whether the user values:
    • official support,
    • local-machine control,
    • messaging-native UX,
    • team visibility,
    • lower cost,
    • or maximum power.

Open Questions / What Still Needs Verification

  1. [Verified unresolved conflict] Which public statement is correct for the Slack connector plan matrix right now?

    • Team/Enterprise only? [Ref 22]
    • All paid plans? [Ref 23]
  2. [Verified but account-specific] Has the user’s Pro or Max account received the Cowork Dispatch / persistent mobile thread rollout yet? [Ref 4][Ref 5]

  3. [Assistant-stated but unverified] Which Telegram/Discord bridge is currently the most stable on Windows + WSL specifically?

    • This document did not perform install/runtime testing.
  4. [Assistant-stated but unverified] Which community projects rely on:

    • direct Claude CLI subprocesses,
    • Claude Agent SDK,
    • copied setup-tokens,
    • or other auth pathways? A code-level audit would be needed.
  5. [Assistant-stated but unverified] How well do these projects behave under:

    • Anthropic usage limits,
    • model changes,
    • auth revocations,
    • Windows service restarts,
    • sleeping/resuming laptops,
    • VPN/proxy environments?
  6. [Assistant recommendation] If the user wants a strict risk-minimized production choice, is Slack + Cowork Dispatch + Remote Control enough, making third-party bridges unnecessary?

Suggested Next Steps

Lowest-risk next step

  • [Assistant recommendation] Test Cowork Dispatch first if the real desire is “message Claude from phone, desktop does the work,” especially for non-code or mixed local-file tasks.
  • [Assistant recommendation] Test Remote Control again only if the need is specifically local coding and repo manipulation.

Team/process next step

  • [Assistant recommendation] If Slack is already central to team ops, test Claude Code in Slack for async task kickoff and visibility, but keep expectations realistic about its limitations.

Third-party pilot next step

If the user still wants a Telegram/Discord-style bridge:

  1. [Assistant recommendation] Choose a pilot candidate:

    • terranc/claude-telegram-bot-bridge for lighter personal use,
    • RichardAtCT/claude-code-telegram for more devops-style notifications/persistence,
    • chadingTV/claudecode-discord if Discord is acceptable and multi-machine control matters. [Ref 11][Ref 13][Ref 14]
  2. [Assistant recommendation] Pilot it only on:

    • a non-production repo,
    • a dedicated machine or VM,
    • a dedicated OS user,
    • no sensitive mounts,
    • no dangerous auto-approve.
  3. [Assistant recommendation] Keep a written rollback plan:

    • revoke bot token,
    • disconnect Claude auth,
    • remove project allowlists,
    • rotate any secrets,
    • uninstall background services.

Follow-up artifact opportunities

  • a Windows + WSL implementation checklist for the chosen path,
  • a security hardening checklist for community messaging bots,
  • a ranked scorecard comparing Telegram/Discord bridge repos,
  • a decision memo choosing one path for Solanasis internal workflows.

Handoff Notes for Another AI

  • The user cares about practical, up-to-date, founder-useful tooling guidance, not just abstract product descriptions.
  • The user is specifically evaluating:
    • local-file access via cloud/mobile surfaces,
    • messaging-native access patterns,
    • subscription-auth versus API-key economics,
    • and smart-cut workflows.
  • Do not assume older pre-March-2026 “Cowork is only desktop” mental models are sufficient. Cowork now has a persistent mobile/desktop thread in research preview for Pro/Max, but work still runs on the desktop machine. [Ref 4][Ref 5]
  • Do not conflate:
    • Remote Control,
    • Claude Code on the web,
    • Cowork,
    • Claude in Slack,
    • Slack connector.
  • Treat any repo README capability claim as unverified unless tested.
  • Treat Anthropic’s OAuth policy statement as a major decision constraint. [Ref 10]
  • Best next move for another AI:
    1. ask which actual workflow matters most: coding, operational tasking, or general phone access,
    2. if a third-party pilot is still desired, produce a ranked implementation plan for the top 2–3 candidate repos with specific Windows/WSL notes and security guardrails,
    3. otherwise, produce an official-only workflow design using Remote Control, Cowork Dispatch, Slack, CLAUDE.md, permissions, MCP, and Chrome/VS Code where appropriate.

Reviewer Notes and Improvements Made

Reviewer capability used: No separate reviewer agent was available. A serious self-review pass was performed.

Corrections and improvements made during self-review

  • [Verified correction] Earlier discussion simplified Cowork as effectively desktop-only with no useful remote path. This artifact corrects that by incorporating the new March 17, 2026 Cowork persistent mobile-thread / Dispatch research preview. [Ref 4][Ref 5]
  • [Verified correction] Earlier discussion leaned on claude remote-control --name "My Project" as the main pattern. Current docs make clear that for a normal interactive local session plus remote access, the cleaner pattern is claude --remote-control "My Project", while claude remote-control is server mode. [Ref 1]
  • [Verified correction] The Slack connector availability story is now explicitly flagged as internally inconsistent across Anthropic docs, rather than being presented with false certainty. [Ref 22][Ref 23]
  • [Improvement] Official Anthropic surfaces were separated from community-project claims so another AI does not accidentally treat README marketing as equivalent to product documentation.
  • [Improvement] Risks were split into:
    • official-feature caveats,
    • policy/support caveats,
    • community-project caveats,
    • strategy caveats.
  • [Improvement] The final recommendations were organized into explicit playbooks so another AI can continue directly into implementation planning.

Optional Appendix — Structured YAML-Style Summary

document_date: 2026-03-17
topic: "Claude remote/mobile/local-file access patterns"
user_goal_summary:
  - "Use cloud/mobile surfaces against local files and local Claude workflows"
  - "Find alternatives to Remote Control that feel like Telegram/Discord/OpenClaw"
  - "Understand what is officially supported vs gray-area community hacks"
  - "Prefer up-to-date, practical, implementation-oriented guidance"
 
official_surfaces:
  remote_control:
    status: Verified
    best_for: "Local coding or local repo work from browser/mobile"
    execution: "Local machine"
    key_limits:
      - "Terminal must remain open"
      - "One remote session per interactive process outside server mode"
      - "Network outage > ~10 min can kill session"
  cowork_dispatch:
    status: Verified
    best_for: "Phone-to-desktop task delegation with local files/connectors/plugins"
    execution: "Desktop machine via Claude Desktop"
    key_limits:
      - "Research preview"
      - "Desktop app must stay open and machine awake"
      - "One continuous thread"
      - "No proactive notifications yet"
  slack:
    status: Verified
    best_for: "Team-visible async task kickoff from Slack"
    execution: "Slack + Claude Code on the web"
    key_limits:
      - "GitHub only for coding tasks"
      - "One PR per session"
      - "No Research / no Extended thinking in Slack"
      - "Weaker for local-machine control"
 
policy:
  anthropic_oauth_reuse:
    status: Verified
    statement: "Free/Pro/Max OAuth is intended only for Claude Code and Claude.ai; reuse in other products/tools/services is not permitted"
 
community_options:
  telegram_bridges:
    status: "Assistant-stated but unverified"
    likely_strength: "High phone UX, local-session feel"
    likely_risk: "Policy/support fragility if subscription auth is involved"
  discord_controller:
    status: "Assistant-stated but unverified"
    likely_strength: "Multi-machine/mobile/team control"
    likely_risk: "Same as above"
  openclaw:
    status: "Verified + mixed"
    strengths:
      - "Large multi-channel assistant framework"
      - "Runs on user's own devices"
    concerns:
      - "Anthropic setup-token is technical compatibility only"
      - "Recent 401 issues with OAuth/setup-token"
      - "API key path is safer"
 
recommended_order_of_operations:
  - "1. Clarify whether the real need is coding, desktop tasking, or messaging-native assistant access"
  - "2. Test official path first: Cowork Dispatch or Remote Control or Slack"
  - "3. Only then pilot a third-party bridge in an isolated environment"
  - "4. Prefer API-key auth over subscription-auth hacks for anything meant to last"
 
open_questions:
  - "Slack connector plan availability docs conflict"
  - "Whether user's account has Cowork Dispatch rollout yet"
  - "Which community bot is most stable on Windows + WSL"
  - "Code-level auth pattern of each candidate bridge"