Locate Remote SSH and container controls

01

Start with the location of each component

Record the user interface, repository, workspace extensions, terminal process and model-request path separately. An editor being visible on a managed laptop does not show where its commands execute or which filesystem they can read. Use non-secret location labels and responsible owners in the worksheet.

Visual Studio Code’s Remote SSH documentation provides a concrete example: it can operate directly on a remote filesystem and run commands and extensions on the remote machine without source code being present locally. Other coding clients and extensions need their own current documentation and observations.

Source context: Visual Studio Code: Remote SSH

02

Review the container boundary as well as the host

VS Code documents that development-container workspaces may be mounted, copied or cloned into the container, and that extensions can run there with access to its tools and filesystem. A container may itself run on a remote SSH host. Record these layers instead of treating “in a container” as a complete security description.

Identify which files are mounted, which credentials the runtime can access and who administers the host and container. This guide does not require changing mounts or opening new remote access. The exercise can use already approved isolated environments with only the supplied synthetic markers.

Source context: Visual Studio Code: Developing inside a container · Visual Studio Code: Remote SSH

03

Place the intended control on the correct path

For each operation, identify where an access rule is enforced and where a submission could be observed. A local filesystem restriction is not evidence of a restriction on a remote host. A browser prompt test does not establish control of an extension or terminal executing elsewhere.

GitHub’s content-exclusion documentation identifies remote-filesystem and symlink limitations. Cursor practitioners have also asked configuration-specific questions about dev-container and sandbox interactions. Use these as reasons to record the exact editor, mode and location, not as proof that every remote workflow is uncontrolled.

Source context: GitHub: Copilot content exclusion · Cursor community: dev-container sandbox question

04

Use location-labelled synthetic observations

The pack contains different markers for local, remote and container fixture locations. If a reviewer is authorised to use existing isolated environments, place the intended marker in each approved location and record which one the selected tool returns. Do not copy real repositories, private keys or credentials into the exercise.

A result should name the component and location tested, not just say “the agent read it.” Record whether the operation was unavailable, denied, prompted or returned a marker. Keep the expected boundary separate from observation, and do not relax a restriction to make every location accessible.

05

Approve the actual execution arrangement

The approval should describe the permitted client, repository location, host/container arrangement and task. Assign responsibility for each boundary. If the runtime or repository moves, revisit the affected rows rather than assuming the same controls follow the window.

Remote development and vendor-hosted cloud agents are different patterns. Use the cloud-access guide when a provider creates a hosted checkout. This page covers the locality of Remote SSH and container-based work and does not imply that Aona governs every remote process from a laptop installation.