HOW THE HELL DO I... Use the Remote File Browser?

Connect host folders, a NAS, SFTP, WebDAV, FTPS and S3 to Agent Zero Files. A practical guide to setup, permissions, remote editing and save conflicts.

#how-the-hell #plugins #tools

HOW THE HELL DO I... Use the Remote File Browser? Part 7: connect the storage, keep control

Your files have achieved independence. The project is on your laptop. The archive is on the NAS. The configuration lives on a server. The deliverables are in a bucket. And somehow you have become the integration layer: download, upload, rename, repeat.

There is a better job for you than being a human file-transfer protocol.

Welcome to Part 7 of How the hell do I... with Agent Zero. The connector and Launcher guide explained how to connect your computer to Agent Zero. This companion goes deeper into Files: one interface for the instance filesystem, a connected host folder, and supported network storage.

The payoff is practical. Browse the right location without mounting every service into Docker. Open supported remote text in the shared Editor. Download or upload through the same Files surface. Grant editing without casually granting deletion. And understand when a refused save is protecting your work rather than ruining your afternoon.

Research basis: source review on October 1, 2026, using Agent Zero Core commit e3051fb, connector 2.13 at 76e834f, and the five screenshot-matched File Browser plugins by 3clyp50, each indexed as 0.1.1 with advertised minimum Agent Zero v2.12. The immutable plugin sources are linked below. These are source-backed instructions, not claims of successful connections to live NAS, SSH, DAV, FTPS or S3 services. Your actual server configuration still needs testing.

First: which computer owns this folder?

Before entering a single password, identify the layer.

Three storage layers: the instance filesystem, a live connector host workspace, and saved network-provider connections

What Files shows Where the files actually live What makes them available
An ordinary path such as /a0 The Agent Zero instance filesystem, often inside Docker The running instance and its filesystem permissions
A0 CLI — … or A0 Launcher — … The computer running the connected CLI or Launcher A live connector exposing that workspace
A named SMB, SSH, WebDAV, FTPS or S3 connection The configured network service An enabled provider plugin, a saved connection and service credentials

“Remote” is relative to Agent Zero, not necessarily to your laptop. A NAS reachable from your laptop may be unreachable from a cloud-hosted Agent Zero instance. The five network providers connect from the Agent Zero runtime; they do not magically borrow your laptop's VPN.

These folders use an application-level namespace such as /@connections/ssh/<connection-id>/…. It is not a kernel mount, a Docker volume or a path you can blindly pass to cd. Connecting a provider also does not turn every shell or file tool into a network-aware tool. Files and the shared remote Editor understand the provider namespace. For other workflows, explicitly transfer the file to the relevant workspace.

One more distinction: /a0 is the local Files starting location, not a security sandbox. The local browser can address the instance filesystem according to its process permissions. Core provider and path contract.

Choose the connection you actually have

The plugins in the episode screenshot are separate adapters, not five names for the same feature.

Your storage Install this plugin Protocol detail that matters
A NAS or Windows file share File Browser SMB 3 for NAS Encrypted SMB3 with signing; a server and a single share
A server with SSH file access File Browser SSH access SFTP over SSH, with a pinned server fingerprint
A DAV-enabled cloud or document service File Browser WebDAV access Verified HTTPS to the final DAV folder URL
An FTP service secured with explicit TLS File Browser FTPS access Explicit FTPS, protected data channel, passive transfers
AWS S3 or compatible object storage File Browser S3 access Bucket/prefix access with explicit credentials and conditional writes

You do not need to install the A0 CLI on the NAS, SSH server or bucket. The network plugins supply their own transports. Conversely, exposing your laptop's workspace through the connector does not require one of these five plugins.

The common setup: install, configure, save, test, open

Animated setup sequence: install and enable the provider, configure the connection, save and test, then open the folder

  1. Open Plugin Hub, search for the exact plugin title above, inspect its source and install it.
  2. Enable it globally. These providers do not use separate per-agent or per-project connection configurations.
  3. Open the plugin's settings and select Open connection settings. Alternatively, open Files → Settings, find Remote folders, and choose Add connection.
  4. Pick the provider, enter a recognizable Connection name, and fill in its fields using the sections below.
  5. Start with Browse folders and Download files only. The new-connection UI selects those by default and leaves mutations off.
  6. Select Save connection, then Test connection. Testing uses the saved connection and tries to list its root; unsaved edits are not what it tests.
  7. Select Open folder or its folder icon. Confirm that the breadcrumb and contents identify the intended server and root before doing anything else.

If a provider is installed but unavailable, check whether it is enabled. If it is not installed, the connection picker can direct you to its Plugin Hub detail. If the expected connection controls are absent, update Core and the provider rather than improvising an unrelated mount command.

A successful test means listing worked. It does not prove upload, editing, deletion or every server extension will work. Test the operations you plan to use in a disposable folder first. Shared UI controls.

Route 1: your laptop through the connector

If you completed Part 6, this is the shortest route.

  1. Connect the host CLI or Launcher to the intended Agent Zero instance.
  2. Choose the workspace on the host side. In Launcher, configure that instance's Host access, select the folder, enable Files read, and leave Files write and Code execution off for a read-only start. Keep the instance open in its Launcher tab or detached window.
  3. With the interactive CLI, use its file-access control; the documented shortcuts are F3 for file read/write and F4 separately for code execution. Inspect the displayed state rather than assuming both are enabled.
  4. In Files → Settings → Remote folders, find the automatically published A0 CLI — … or A0 Launcher — … entry.
  5. Use Test connection, then Open folder.

These entries are managed connections. Files does not give you ordinary edit/remove controls for their root and credentials; change access in the connector or Launcher. Disconnecting, reconnecting or changing the root can invalidate the old logical path, so reopen the current entry instead of bookmarking its generated ID.

If the row says Update and restart the Connector to browse this folder, do exactly that. The server needs a client advertising the file-browser capability, not merely an old CLI that can chat.

For host file browsing, the connector applies workspace containment and write checks. Those checks are not a sandbox for separately enabled host terminal commands. Also, source review found a Windows-only path-helper mismatch in connector 2.13; Windows host Files interoperability was not established by this research. Test the actual version you install before relying on it for important edits. Host-folder provider.

Route 2: SMB3 for your NAS

Select SMB 3 for NAS and enter the fields separately:

Field What to enter
Server name The NAS/server hostname or supported address, not a complete UNC path
Share name One share, such as projects, not \\server\projects
Folder within share Optional subfolder, such as team/reports; blank exposes the configured share root
Username A registered account; DOMAIN\user if your server requires it
Password That account's password
Port Normally 445

Example shape: server nas.example.net, share projects, folder demo. These are illustrative values; substitute your own service and a deliberately restricted account.

Save, test, open. If it fails, verify that Agent Zero's runtime can reach the NAS, that the account has share and filesystem permissions, and that the server supports SMB3 encryption. The adapter requests both encryption and signing and rejects older dialects. Turning on SMB1 or guest access is not the fix.

Use a direct share rather than assuming DFS namespace support. Symlinks/reparse points are rejected by the adapter. SMB “signed sessions” means SMB transport signing—not a universal signature on every Editor session or saved connection file. SMB setup and limitations.

Route 3: SSH access means SFTP—not a terminal

Select SFTP over SSH. Enter the server, SSH port (normally 22), an absolute remote folder, username, and optional password.

Before saving:

  1. Click Check server identity.
  2. Compare the returned SHA256 fingerprint with one obtained independently from the server administrator or a trusted management channel.
  3. Only after it matches, select I trust this server fingerprint.

The probe tells you what the contacted server presented. It does not independently prove that this is your server. Accepting it without comparison defeats the reason for pinning it. Changing the host or port resets the trust decision.

For key login, choose Create instance SSH key, then Show public key or Copy public key. Have the administrator install only the public key in the remote account's ~/.ssh/authorized_keys. Keep the private key on the Agent Zero instance. This plugin uses its instance key and/or supplied password; it does not automatically consume your laptop's SSH agent or arbitrary local private-key files.

Save, test, open. Browse and download first. For editing, the server needs the OpenSSH POSIX rename extension used by the safe-save path. A server can support SFTP listing yet fail this particular replacement operation. The adapter does not solve that by deleting the original first.

This plugin grants file access over SFTP, not SSH shell execution. Use server-side account restrictions to enforce the real directory boundary. SSH setup, trust and key workflow.

Route 4: WebDAV over HTTPS

Select WebDAV over HTTPS. Supply:

Field What to enter
WebDAV folder URL The final HTTPS DAV collection URL, not the service's ordinary website homepage
Username The registered DAV account
Password or app password The credential that service expects for DAV
Trusted CA file Optional trusted CA file path inside Agent Zero, not on your laptop

For a Nextcloud-style service, the URL may resemble https://cloud.example.com/remote.php/dav/files/user/. Use the address your service actually documents.

TLS certificate verification is enabled. Redirects are rejected: configure the final HTTPS address rather than expecting credentials to follow a redirect chain. A private CA belongs in the trusted CA configuration; disabling verification is not an exposed setup option.

Remote editing requires a strong ETag for replacement and a server that honors conditional writes. Listing can work while editing fails because the server omits ETags or returns weak ones. That is a meaningful protection, not an invitation to force an overwrite. WebDAV setup and save contract.

Route 5: FTPS, with the letters in the right order

SFTP is SSH. FTPS is FTP protected by TLS. They are not interchangeable because they both happen to move files.

Select FTPS (explicit TLS). Enter a server name, port (normally 21), absolute remote folder, registered username and password. Optionally provide a trusted CA file inside the Agent Zero runtime.

The server must support explicit TLS, a protected data channel, passive transfers, and MLSD directory listings. This plugin does not support plain FTP, anonymous login or implicit port-990 FTPS. Changing the port number to 990 does not change the implementation into an implicit-TLS client.

If authentication succeeds but listing or transfer hangs, check the server's passive-port configuration and firewall from the Agent Zero runtime's network. If listings fail, confirm MLSD support. Use a jailed account: a folder setting in a client is not a substitute for server-side confinement.

FTPS saves upload a temporary sibling, check the current content hash and rename the new file into place. Standard FTP rename is not an atomic conditional-write protocol; another writer can still race the final check. Avoid simultaneous edits to important files and retain backups. FTPS requirements and concurrency limits.

Route 6: S3 and compatible storage

Select S3 object storage and enter:

Field What to enter
Bucket The bucket name, not an ARN or s3:// URL
Key prefix Optional scope such as team/demo; blank starts at the bucket root
Region Your service's region; shipped default is us-east-1
HTTPS endpoint Blank for AWS endpoint selection; the verified HTTPS endpoint for a compatible service
Access key ID / Secret access key Explicit credentials restricted to the intended bucket/prefix
Session token Include it when using temporary credentials

This revision requires explicit keys. It does not expose an instance-role-only setup or automatically renew expired temporary credentials. Rotate/update the saved values when necessary.

On AWS, a typical read workflow needs s3:ListBucket on the bucket and s3:GetObject on the allowed objects. Upload/edit generally needs s3:PutObject; deletion needs s3:DeleteObject. These are operational starting points derived from the adapter's operations, not a universal tested IAM policy. Bucket policies, explicit denies, KMS and retention rules can add constraints. Enforce the prefix in IAM as well as in the UI.

S3 folders are prefixes or marker objects, not normal filesystem directories. Rename/move is unavailable because this adapter does not pretend that copy-and-delete is an atomic rename. Conditional saves require an endpoint supporting the relevant IfMatch/IfNoneMatch writes. Deleting a versioned object does not purge its historical versions. S3 setup and limits.

Permissions: six choices, not one giant yes

Six independent Files permissions, with browse and download as the starting pair and mutations deliberately separate

Permission What it authorizes
Browse folders Directory listing and Test connection
Download files Download/read delivery through Files
Upload files and create folders New file uploads and folder creation
Open and edit files Remote Editor access and revision-based replacement
Rename and move files Supported moves within the same connection
Delete files and folders Deletion; treat folder removal as potentially destructive

Editing necessarily exposes file contents. Disabling Download does not turn an account with Edit into a “cannot read” account. And these are Files-operation permissions, not a global restriction on a user or agent that already has shell access, other credentials or broader host rights.

For a review-only connection, keep Browse and Download. For text maintenance, add Edit only when needed. For publishing, add Upload. Reserve Rename and Delete for explicit tasks. The UI disables unsupported actions; S3's missing rename is intentional.

The remote account's own ACLs/IAM remain authoritative. A checkbox can restrict what this interface attempts; it cannot grant an operation the server refuses. Core permission enforcement.

Editing without casually overwriting someone else's work

Open a supported remote text/code file in the shared Editor, make a small change, and save. This is bounded UTF-8 text editing—not a promise that remote DOCX, spreadsheets or PDFs open directly in Office. Download those for the appropriate local workflow, then upload the resulting file when permitted.

Safe-save diagram: retain the revision when opening, compare it when saving, and stop on conflict rather than overwrite blindly

When a remote file opens, Core retains its provider revision and passes that expected revision back on save. What happens next depends on the provider:

Backend Save protection Limit to remember
WebDAV Strong ETag and HTTP conditional PUT Server must supply and honor the condition
S3 ETag-based conditional object write Compatible service must implement conditional writes
Host, SMB, SFTP, FTPS Hash/revision checks with staged replacement A final check-to-replace race is still possible

If a save reports a conflict, preserve your edited text, reopen the current remote file, compare the changes and merge deliberately. Do not retry blind overwrites until the error disappears. Save conflicts exist because someone else's work is worth keeping too.

The shipped defaults are 10 MiB for text editing, 100 MiB for transfers, 100 MiB expanded archive content and 1,000 archive entries. These are configurable instance limits, not promises that every server accepts files that large. Increasing them consumes runtime memory/disk and does not remove protocol limitations.

For transfers between different connections, use download, then upload. Do not assume cross-provider drag-and-drop, cross-connection rename or a remote-to-local Save As operation exists. Directory/multiple-file downloads may be packaged as ZIPs, subject to limits. Shared Editor and transfer implementation.

A five-minute acceptance test before real work

Create a disposable test folder using the service's own trusted administration interface. Then:

  1. Connect with Browse/Download only. List the folder and download a known text file. Confirm mutation actions are unavailable.
  2. Enable Upload for this test connection. Create a small, uniquely named text file; confirm its contents through a second trusted client.
  3. Enable Edit. Open that file, change one line, save, reopen and compare.
  4. Try a deliberate stale-save test: keep it open in Agent Zero, change the remote copy from another client, then attempt to save the old Editor version. Expect a conflict—not silent loss of the other change. This checks one conflict scenario, not every possible race.
  5. Test Rename only on providers that support it, and Delete only on a disposable item. Confirm server restrictions still win.
  6. Restore the smallest permission set you need. Disable the provider and confirm its connection becomes unavailable; re-enable only when wanted.

Now you know more than “the green test button worked.” You know whether the operations you will actually use behave correctly against your actual service.

Where the secrets live

Saved provider connections live in the Agent Zero instance's plugin data directories, typically /a0/usr/plugins/<plugin-name>/data/connections.json. The shared helper writes credential-bearing JSON with restrictive file permissions and redacts secret fields from public connection responses. That is not encryption at rest. Protect the instance storage and backups accordingly.

A saved-secret field shows Saved; leave unchanged to keep it. Preserve that state when editing unrelated settings instead of inserting a dummy password. SSH instance keys also belong to instance storage; only the public key should leave for installation on the remote account.

Removing a saved connection removes its configuration, not the remote data or the service account. Disabling a provider prevents Files from using it; it does not revoke the underlying password/key at the service. Revoke or rotate credentials there when access should truly end. Managed host entries are different: disconnect them from the CLI/Launcher.

Troubleshooting without guessing

Symptom Check first
No provider in Add connection Correct plugin installed, globally enabled, compatible Core
Your laptop connects but Agent Zero cannot DNS, routes, VPN and firewall from the Agent Zero runtime
Test succeeds, upload fails Upload permission and service-side write rights
SSH refuses the connection after a server change Verify the new fingerprint independently; do not blindly accept it
SFTP reads work but saves fail POSIX rename extension, permissions, concurrent edits
WebDAV rejects the address Final HTTPS DAV folder URL; no redirect or embedded credentials
WebDAV opens but refuses replacement Strong ETag support and conditional-write behavior
FTPS login works but data operations fail Passive ports, protected data channel and MLSD support
S3 listing works but reading fails Object permissions, bucket policy, encryption requirements and token expiry
Rename missing on S3 Expected: the adapter does not implement it
Host folder disappears Live connector, exposed root, selected instance, current permissions
Text file cannot open in Editor UTF-8, nonbinary content, supported file type and configured size limit

The point is less copying—and better boundaries

You do not need to mount the entire universe into Docker. You need the right connection, the right account and the smallest permission set that gets the job done.

Start with one remote folder. Browse it. Download one known file. Make one disposable edit. Prove the round trip before handing it anything important.

Then retire from your unpaid position as human file-transfer protocol.

Continue the series: Get the most out of Agent Zero with the connector and Launcher. For organizing the work itself, revisit Projects and Plugin Nester.