_{Chat → Remote Arc → your computer. Animated preview from the interactive demo in PR #101 (example data, no real device commands). Click to explore the workflow.}

Two ways to work

Product	Start here	What it does
Arc	Hosted workspace	Chat with a personal agent, use connected Apps/computers, reuse Skills, and create one-off Tasks or recurring routines.
Connect	Connect your AI	Use authorized cloud accounts and paired devices from compatible ChatGPT, Claude, Codex, Cursor or other MCP clients.

Arc keeps a delegated responsibility together: its sources, instructions, conversation and run history, with fresh bounded judgment when scheduled and checks against actual results. Start with a daily work brief, project check-in, delivery verification or change follow-up. The use-case catalog also keeps Arc and Connect paths for all 15 concrete workflows.

Arc offers an explicitly activated 14-day Auto trial and Plus / Pro subscriptions. Users do not supply a model API key. Hosted model use has Credits and run limits; available models and plan details are shown in the workspace. Connect calls and third-party App charges have their own allowances. Preview environments use simulated data.

From a goal to a result

1. Connect what the work needs. Authorize a cloud account in Apps, or pair a computer for local files, commands and installed software. Cloud Apps do not require a local computer.
2. Describe the outcome. Ask for an inbox summary, an issue with a returned link, or a deployment check. Type @ in Arc Chat to reuse a selected cloud/imported skill, then describe the desired result.
3. Execute within current permissions. Models interpret, plan, choose tools and summarize. Arc supplies bounded context, typed operation contracts, authorization, dispatch, persisted observations and cost accounting.
4. Inspect the result. A connection check or successful individual tool call is not the whole goal. Chat presents the final answer; Activity provides execution details. Missing permissions, engines, devices or budgets must be reported as blockers.
5. Keep ongoing work. Ask Arc to save a one-off Task or a routine with accounts, timing and timezone. Runs are persisted and scheduled; failed or uncertain recurring work pauses for inspection.

Earn trust through execution

• Evidence: return observed content, an acknowledged resource or a concrete blocker; a tool call alone is not task completion.
• Boundaries: current account permissions and local policy apply to each action; skill text and messages cannot grant more authority.
• Continuity: retain useful context and results; stop rather than blindly repeat an uncertain external write.
• Control: users can stop work, revoke connections, inspect Activity and manage memory; budgets bound hosted execution.

The run status records whether execution ended. Verify the answer and its evidence to assess the goal. The technical reference describes current tests and limits instead of promising that an agent can complete any possible task.

Platform capabilities

• Connected Apps: account-owned, typed provider operations with live scope checks, stable request identities and recorded outcomes.
• Tasks and routines: saved goals, schedules, leases, bounded hosted runs and result history. Connect also supports deterministic background commands and checks.
• Verified results: optional exact account/resource contracts, independent result checks and source-derived execution receipts. See the user guide and feature map.
• Skills: reusable cloud instructions and imported SKILL.md references. A skill does not install its required engine, scripts or dependencies.
• Context and memory: relevant prior observations and learned IDs within a chat, plus bounded encrypted personal notes and work summaries users can inspect and delete.
• Device fleet: filter by ownership, tools, workspace and availability before balancing fresh capacity. Projects are not moved implicitly.
• Local control: read-oriented initial setup, explicit file/terminal/browser permissions, trusted roots, sensitive-path checks and supported Local Undo.
• Outbound connectivity: paired Windows, macOS and Linux computers connect outward; no public inbound port or VPN is required.
• Operating controls: Credits, funding reservations, separate paid/sponsored budgets, billing records and admin usage visibility.

Architecture

flowchart TB
  User[User] --> Arc[Arc hosted workspace]
  User --> External[External AI client]
  External --> Connect[Connect / OAuth MCP]
  Arc --> Runtime[Arc runtime and bounded context]
  Runtime <--> Model[Configured model API]
  Runtime --> Gate[Authorization and dispatch]
  Connect --> Gate
  Runtime <--> State[(Encrypted content / tasks / usage)]
  Scheduler[Leased scheduler] --> Runtime
  Gate --> Apps[Cloud App adapters]
  Gate --> Route[Device selection and routing]
  Route <-->|Outbound authenticated WSS| Agent[Native Go Agent and Execution Core]

The model is the reasoning component; Remote Arc owns the execution and continuity layer. Provider data, skill text, files and memory remain untrusted observations. Unknown external effects are retained for inspection and are not blindly repeated. A completed run is not a universal semantic proof of success; inspect the returned evidence.

Read the current engineering reference for run state, context reuse, security boundaries, memory limits, scheduling, funding and validation. Public technical documentation explains the same system for users. Configurable employees, dedicated direct/group conversations and scoped teammate handoffs are implemented in the AI Teams development branch and remain unreleased; see the feature map. Cross-run persistent goal continuation and full root-outcome acceptance remain incomplete; see the implementation/design status. Ordinary Connect cannot wake an arbitrary external chat.

Quick start

For hosted Arc, sign in, activate the trial or choose a plan, connect an App and describe your goal. Install a device Agent only for work that needs your computer:

npx remotelink@latest

The npm launcher installs and checksums the native Go Agent and Execution Core. Run npx remotelink@latest to upgrade: an older idle Go Agent is replaced automatically, while active work asks for confirmation. Pairing and permissions are preserved. Stop the active Agent before switching runtimes; --ts explicitly selects the retained TypeScript fallback. Standalone and Homebrew installations need no Node.js.

Native downloads and Homebrew

Standalone 0.6.5 needs no Node.js or Go compiler. Installation and upgrade guide.

On macOS or Linux (including WSL), install without Node.js:

curl -fsSL https://remotearc.app/install.sh | sh
remotelink

The script verifies SHA256, installs to ~/.local/bin without sudo, and leaves pairing and permissions for the first launch. Set REMOTEARC_INSTALL_DIR to an absolute path to choose another directory. Rerun the installer to upgrade after stopping the Agent.

Platform	Download
macOS Apple Silicon	remotelink
macOS Intel	remotelink
Windows x64	remotelink
Windows ARM64	remotelink
Linux x64	remotelink
Linux ARM64	remotelink

SHA256SUMS · Release notes

brew tap yaohuangguan/remote-arc https://github.com/yaohuangguan/remote-arc
if brew command trust >/dev/null 2>&1; then brew trust --formula yaohuangguan/remote-arc/remotelink yaohuangguan/remote-arc/remotelink-go; fi
brew install yaohuangguan/remote-arc/remotelink
remotelink

The existing remotelink-go formula remains available for upgrades; install one formula at a time.

For Connect, authorize your compatible AI client against:

https://mcp.remotearc.app/mcp

Pairing a computer and authorizing an AI client are separate, revocable relationships. See installation, Apps, Tasks, Skills and memory.

Monorepo

remote-arc/
├── apps/
│   ├── agent/            Native Go device Agent: pairing, relay, recovery, journals
│   ├── agent-ts/         Explicit TypeScript runtime fallback
│   ├── ui/               React Arc / Connect / Admin, website and documentation
│   ├── relay/            Cloudflare Worker, Arc runtime, Apps, tasks, billing, OAuth and MCP
│   └── mcp/              TS compatibility adapter and native MCP integration tests
└── packages/
    ├── execution-core/   Independent Go module: files, processes, policy and Undo
    ├── execution-core-ts/ Retained TypeScript core for --ts and parity testing
    ├── cli/              npm installer/launcher; default Go, explicit --ts
    └── protocol/         Shared wire types for Relay, Dashboard and TS compatibility

The Go Agent and Execution Core compile into one executable; extracting the core
does not introduce an IPC boundary. The core can be built/tested independently
with Go. Both engines preserve tool contracts, pairing, file/Undo formats and a
single execution lease. The cloud Relay and Dashboard remain TypeScript.

Native execution core

Remote Arc implements its local computer capabilities directly with Go and OS
APIs. The retained TS implementation is used only when --ts is selected.

Current native tools:

list_directory
browse_directories
read_file
read_binary_file
get_file_info
list_processes
write_file
edit_block
list_undo_actions
undo_change
undo_last_change
start_process
process_status
process_output
list_managed_processes
stop_process

The primary core uses Go's os, filepath, os/exec, context and native
platform APIs. It owns bounded process output, cancellation, atomic replacement,
local Undo evidence, conflict fences and path policy. The Agent adds authenticated
outbound sessions, device configuration, checkpoints and local execution journals.

Atomic replacement and explicit durable synchronization are separate policies.
TS retains its atomic default; Go retains its durable default. This release does
not claim complete hardware power-loss protection. See the
persistence validation and
system architecture for boundaries and evidence.

Permission model

New devices start with the Safe preset.

Safe

Read-only local capabilities:

list_directory
read_file
read_binary_file
get_file_info
list_processes

The native core also has internal dashboard capabilities such as
list_undo_actions and browse_directories. They let the authenticated
Remote Arc dashboard load local recovery metadata and browse selectable folders
without turning those controls into normal hosted AI skills.

Developer

Safe plus reversible file editing:

write_file
edit_block
undo_last_change

The dashboard can additionally invoke the internal undo_change operation to
restore a selected local snapshot.

Developer mode does not include arbitrary terminal execution.

Full

Developer plus:

start_process
process_status
process_output
stop_process

start_process can run synchronously or return a local process handle for a
managed background process. Output and status stay on the device and are read
through the same authenticated Remote Arc tool path. The dashboard uses the
internal list_managed_processes capability to show these Remote Arc-managed
jobs and lets the user inspect output or stop a running process.

Presets are shortcuts. The actual hosted policy is an individually editable
per-device skill list.

Durable Automations

Remote Arc can persist deterministic work independently of the chat session that created it. MCP clients need the separate automation:read / automation:write OAuth scopes to inspect or create persistent work; ordinary computer:write access does not grant that authority.

Four production task modes share the same durable task engine:

• Long task — start a command and keep tracking it after the MCP call/chat ends.
• Condition watch — wait for a webhook event, then execute an approved plan.
• Schedule watch — execute a plan on a recurring interval or at a future time.
• Goal loop — repeat a fixed work plan, execute a verification command, and retry until verification succeeds, the task expires, the run limit is reached, or the user stops it.

Condition watches may also use a cloud-side GitHub App merge action. A matching CI webhook can therefore merge an explicitly configured pull request without depending on a paired computer being online.

Automation state lives in D1 and is advanced by the Worker scheduler or webhook events. Device execution still goes through the same authenticated Durable Object route and the device's existing skill/path policy.

Creating an automation snapshots the current device permission policy. Routine disconnects and local agent restarts do not introduce an approval step: unattended work waits for the device and automatically recovers. If you later change the device security policy itself, Remote Arc stops that automation rather than silently inheriting a different trust boundary.

A device going offline moves eligible work to waiting_for_device; it does not automatically fail the automation. Deterministic long-running work defaults to automatic attempt restart if the local agent reconnects without its previous managed-process handle. For fresh AI judgment, Arc hosted tasks invoke their configured model within current limits. Deterministic Connect tasks need an available supported reasoning host for new decisions; this does not imply an autonomous wake loop into arbitrary external chats.

The background agent and automation engine solve different problems:

• the background agent keeps a paired device available and reconnecting without an open terminal window;
• the automation engine preserves task state and triggers independently of an MCP request or chat lifetime.

A sleeping, powered-off, or disconnected computer is not considered online. Device-backed work resumes only after the agent reconnects.

Running:

npx remotelink --safe

adds a local hard read-only cap that the dashboard cannot expand.

Local Undo

Before supported write_file and edit_block operations, Remote Arc stores
the previous file state locally under:

~/.remotearc/undo

Properties:

• snapshots stay on the device
• snapshots are not uploaded to Remote Arc Cloud
• snapshots expire after 7 days
• the local store is capped at 200 MB
• individual files larger than 20 MB are not snapshotted
• undo verifies the post-edit file hash before restoring
• if a file changed again afterward, automatic undo refuses to overwrite it

Local Undo cannot reverse external side effects such as deployments, package
publishing, network requests, or remote database mutations.

The dashboard can load undo metadata directly from an online device on demand
and restore a specific action. Each row reports whether the current file still
matches the recorded post-edit state. Conflicted, missing, or legacy snapshots
are shown as unavailable instead of attempting an unsafe overwrite. Undo history
is not persisted in D1 or another Remote Arc cloud store.

Sensitive Path Policy

Sensitive-path protection is enabled by default in the native execution core.

Built-in protected locations include common credential and profile areas such
as:

~/.ssh
~/.aws
~/.gnupg
~/.azure
~/.kube
~/.docker
~/.config/gcloud
browser profile directories
.env and .env.*

Users can add additional protected paths per device in the dashboard. When a
specific project genuinely needs a protected file such as one .env, users can
add a narrow sensitive-path exception for that exact file or directory without
turning off protection globally. A sensitive-path exception grants visibility
only; it does not create write authority outside Trusted Write Locations.

Path checks happen again on the local device immediately before filesystem
execution. Canonical-path checks prevent a symlink inside a trusted write
location from turning a permitted mutation into an out-of-scope write.

The selected trusted-write/protected-path strings are control-plane policy
metadata stored in D1; saving a path does not copy its file contents. Durable
deterministic Tasks store only the task contract, bounded run state and result
metadata needed for their lifecycle.

Trusted Write Locations and boundary approvals

A device can define one or more Trusted Write Locations. These are the folders
where supported file mutations may happen repeatedly without asking for a new
approval every time. The dashboard supports manual path entry and a
device-backed directory picker.

Trusted Write Locations are deliberately not the AI's visible world.
Read-only filesystem tools may inspect ordinary non-sensitive files outside
those locations. Supported mutations such as write_file and edit_block
must stay inside a Trusted Write Location or receive a narrowly scoped boundary
approval before execution.

An out-of-scope write can be approved once, allowed briefly for the same
file/tool, promoted by trusting the parent folder, or denied. One-shot approvals
are consumed after successful execution. Approval metadata is bound to the
account, device, OAuth client/grant, tool, target path and request details.

For Full mode, start_process remains a separate high-risk capability. When
Trusted Write Locations exist, terminal calls require an in-scope cwd, but
that check is not an operating-system sandbox: a shell running from an
allowed directory may still reference other paths, credentials, network
services or child processes.

Native-core reliability

File rewrites and targeted edit_block changes use same-directory temporary
files followed by rename, reducing the risk of leaving partially written files
after an interrupted write. Append mode remains append semantics and is not
described as an atomic rewrite.

Safety Guard

Terminal execution is available only when the device policy allows
start_process.

Before a terminal command runs, the native execution core blocks a narrow set
of clearly catastrophic patterns such as:

• recursive deletion of root/home paths
• disk formatting
• raw-disk overwrite
• fork bombs
• machine shutdown/reboot

The Safety Guard is defense in depth, not a complete OS sandbox.

Authentication and trust boundaries

Remote Arc separates four identities:

1. dashboard user
2. MCP client
3. paired device
4. live device connection

Dashboard

Users sign in with Google. The Worker creates a secure HTTP-only session.

MCP client

Remote MCP uses OAuth 2.1 authorization code flow with PKCE and dynamic client
registration. The Security dashboard tracks each OAuth authorization instance
separately and labels it as active, refreshable, or expired. Revoking one grant
invalidates that client authorization without revoking paired computers or
other AI-client grants.

Discovery:

/.well-known/oauth-protected-resource
/.well-known/oauth-authorization-server

OAuth endpoints:

/oauth/register
/oauth/authorize
/oauth/token

Device

Every paired device receives its own revocable credential.

The raw device credential is stored locally in:

~/.remotearc/config.json

The hosted database stores only its SHA-256 hash.

Routing

Live devices connect outbound over WebSocket to a per-user Durable Object.
Remote Arc does not require inbound access to the computer.

Cloudflare deployment

Production:

Website: https://remotearc.app
MCP:     https://mcp.remotearc.app/mcp
Health:  https://mcp.remotearc.app/health

The hosted architecture currently uses:

• Cloudflare Workers
• Workers Static Assets
• per-user Durable Objects
• D1 for control-plane state
• outbound device WebSockets

Static JS/CSS/assets bypass the Worker runtime so normal website traffic does
not unnecessarily consume the Workers request quota.

Production deploys are intentionally single-path: a successful CI run on
master triggers .github/workflows/deploy-cloudflare.yml, which is the normal
way production is updated. Local pnpm deploy:relay is blocked to prevent a
second Wrangler deploy racing the CI deployment. For an emergency-only manual
production deploy, use:

REMOTEARC_MANUAL_PROD_DEPLOY=1 pnpm deploy:relay

Every allowed deploy writes the verified Git SHA into the Cloudflare version tag
and message so production history can be traced back to its source commit. GitHub
Actions also verifies origin/master immediately before the build and again
before upload; if a newer master commit exists, the older successful CI run exits
without deploying.

Remote MCP tools

Hosted MCP currently exposes 27 user-facing tools. Device-execution tools are still filtered by the selected device's policy and live capabilities:

list_devices
device_tools

shared_tab_list
shared_tab_read
shared_tab_click
shared_tab_fill

list_directory
read_file
read_binary_file
create_file_resource
revoke_file_resource
get_file_info
list_processes
start_process
process_status
process_output
stop_process
write_file
edit_block
undo_last_change

create_automation
list_automations
get_automation
manage_automation

The automation tools create and manage durable deterministic control-plane state. They do not grant new device capabilities: when an automation executes on a computer, the normal device ownership, skill policy, Trusted Write Locations, boundary approvals and Sensitive Path Policy checks still apply. Per-device task permissions independently govern background, scheduled and keep-awake behavior.

Adaptive Agent Goal/source-decision work remains an experimental implementation behind a disabled production feature flag. It is intentionally absent from the shipped MCP tool contract because ordinary Chat cannot yet be autonomously woken for fresh reasoning after the creating turn ends. The engineering notes remain in the repository for continued research.

See the complete system architecture,
implementation plan,
resume checkpoint and the website guide
at /docs/long-running-work. Real Plugin/Chat/Work overnight acceptance remains
pending. Local Wrangler tests prove relay execution/recovery, not host lifetime.

Before a device call is forwarded, the relay verifies:

• authenticated MCP user
• device ownership
• device revocation state
• saved per-device skill policy
• currently advertised device tools

Development

Requirements:

• Node.js 24+ for the TypeScript development tools and SQLite test suite (npm/npx installation: Node.js 20+; native downloads and Homebrew need no Node.js)
• Go 1.25.5 for native Agent and Execution Core development
• pnpm 10
• Cloudflare Wrangler for relay work

Install:

git clone https://github.com/Remote-Arc/remote-arc.git
cd remote-arc
pnpm install
pnpm run ci

Useful commands:

pnpm dev:mcp
pnpm dev:agent
pnpm dev:relay
pnpm dev:ui

pnpm build:cli
pnpm build:ui
pnpm test:deploy-policy
# production deploys run automatically after CI on master

Run only the native execution-core-ts integration test:

pnpm --filter @remotearc/execution-core-ts test:integration

The GitHub CI matrix runs native-core integration and MCP adapter smoke tests
on:

Ubuntu
Windows
macOS

Publishing the CLI

The npm package name is:

remotelink

Product name:

Remote Arc

The package also exposes these CLI aliases:

remotelink
remote-link
remote-arc

The published CLI bundles @remotearc/execution-core-ts into the distributable
artifact. End users do not install a separate execution server.

Release content has one source of truth: CHANGELOG.md. Each release section uses
## <version> - <date>, one ### <title>, and bullet changes. Run:

pnpm release:sync
pnpm release:check

release:sync updates the npm README's Latest release block. The website Releases
page reads the same CHANGELOG at build time, and the GitHub Release workflow uses
the same section as its release notes. CI fails when the package version and latest
CHANGELOG section drift apart.

npm publishing uses GitHub Actions OIDC Trusted Publishing with provenance.

The npm Trusted Publisher configuration must match:

Organization or user: yaohuangguan
Repository:           remote-arc
Workflow filename:    publish-remotelink.yml
Environment name:     production
Allowed action:       npm publish

Security model

Remote computer access is high impact. Remote Arc therefore starts from a
restricted capability model instead of granting unrestricted terminal access.

Current protections include:

• read-only default preset
• individually editable device skills
• local hard Safe mode
• per-device credentials
• hashed device credentials in D1
• OAuth 2.1 + PKCE
• per-user Durable Object routing
• revoked-device checks before MCP forwarding
• outbound-only device connections
• Local Undo for supported file changes
• on-demand Local Undo history from the device
• Sensitive Path Policy enabled by default
• configurable Trusted Write Locations and boundary approvals
• canonical/symlink-safe filesystem path enforcement
• atomic rewrite/edit operations
• local Safety Guard for catastrophic terminal commands
• no Desktop Commander dependency

Still planned before broader public use:

• stronger secret redaction in audit metadata
• more granular command/network policy
• signed/notarized installers
• background service / auto-start
• auto-update

Roadmap

Phase 1 - core platform

• Cloudflare relay
• D1 identity/device/OAuth model
• per-user Durable Object routing
• Google sign-in
• OAuth 2.1 + PKCE Remote MCP
• browser-approved device pairing
• one-command remotelink CLI
• per-device skill management
• Safe / Developer / Full presets
• Local Undo
• targeted Local Undo history UI
• Sensitive Path Policy
• Trusted Write Locations + boundary approvals
• atomic file rewrites
• Safety Guard
• native Remote Arc execution core
• remove Desktop Commander dependency
• Windows/macOS/Linux CI
• production relay deployment
• publish native-core CLI to npm

Phase 2 - local security and reliability

• process handles and background jobs
• streaming command output
• richer Windows/macOS/Linux process support
• signed/notarized installers
• background service / tray/menu-bar agent
• auto-update

Phase 3 - public product

• broader multi-user security review
• improved audit history
• organization administration
• public ChatGPT integration/discovery
• production observability and abuse controls

License

Remote Arc is source-available, not open source for current releases.

The current source is licensed under the
Remote Arc Proprietary Source License. Viewing and security review
are permitted, but modification, redistribution, white-labeling, and commercial
exploitation require written permission.

Historical revisions previously released under MIT remain governed by the MIT
terms that applied to those revisions.

Third-party components continue to use their own licenses.