How the Compasify connected-device tunnel works

The agent initiates the connection

A connected machine runs the Compasify agent and establishes an authenticated outbound session. This is easier to operate across common firewalls than exposing a general remote shell directly to the internet. The account pairs with a short-lived code, while the installed agent receives its own revocable device identity. For connected device tunnel, a dependable implementation begins with a written baseline: the current behavior, the intended result, the account or device involved and the person responsible for review. Test with a realistic low-risk example, record the result and keep a clear way to stop or reverse the workflow. This turns the agent initiates the connection from a feature description into an operating practice that another person can understand and repeat.

• Outbound agent session
• Short-lived pairing code
• Revocable device identity

Capabilities remain separate

File access, commands, processes, remote viewing, remote input, databases and add-ons represent different risk levels. They should be enabled independently and checked on both the server and the agent. Sharing a device with another Compasify user must not imply unrestricted control. When applying capabilities remain separate, include the less convenient cases in the design. Check what the user sees when data is missing, access has expired, a provider responds slowly or only part of an operation succeeds. Status messages should identify the affected item and the next useful step without exposing credentials or internal protocol noise. Revisit the setup after real use and remove assumptions that the evidence does not support.

• Granular capabilities
• Server and agent checks
• Share-specific permissions

Sessions need health and recovery

Heartbeat data indicates whether an agent is reachable, but service health also depends on command processing and streaming channels. Reconnection should resume safely without duplicating queued actions or leaving keyboard state active. Logs need timestamps and request identifiers that can be matched across the browser, service and agent. For connected device tunnel, a dependable implementation begins with a written baseline: the current behavior, the intended result, the account or device involved and the person responsible for review. Test with a realistic low-risk example, record the result and keep a clear way to stop or reverse the workflow. This turns sessions need health and recovery from a feature description into an operating practice that another person can understand and repeat.

• Heartbeat and capability health
• Safe reconnect
• Traceable activity

A tunnel is not unlimited system access

The agent operates under the Windows or Linux account used by its service. Approved roots and operating-system controls still matter. High-risk commands require careful policy, and users should maintain independent backups. The connection can be powerful while remaining explicit and removable. When applying a tunnel is not unlimited system access, include the less convenient cases in the design. Check what the user sees when data is missing, access has expired, a provider responds slowly or only part of an operation succeeds. Status messages should identify the affected item and the next useful step without exposing credentials or internal protocol noise. Revisit the setup after real use and remove assumptions that the evidence does not support.

• Operating-system boundaries
• Approved file roots
• Independent backups

Questions about connected device tunnel