Object Storage AWS S3

Adds AWS S3 to the Object Storage extension, so your buckets show up alongside every other backend you have connected.

What you can do

• Connect to S3 with an access key and secret, in whichever region you work in
• Use temporary STS credentials by adding a session token
• Browse your buckets and objects from the Object Storage panel
• Download an object into your workspace, and upload a workspace file back
• Reach a VPC or FIPS endpoint through a custom endpoint, with path-style addressing when you need it

Requirements

The Object Storage extension, installed and enabled, and the desktop app.

This is a provider: it owns the S3 client and the "Connect AWS S3" form, but no panel of its own. Install extension-object-storage alongside it; the hub renders the connections tree, the object list and the transfer panel, and dispatches every operation here.

Getting started

Open Object Storage in the activity bar → + → AWS S3.

Field	Notes
Region	Required, e.g. eu-central-1. The endpoint is derived from it.
Access key ID / Secret access key	Stored in the OS keychain, never in a workspace file.
Session token	Only for temporary STS credentials (ASIA…). Leave blank otherwise.
Custom endpoint	Optional — for VPC or FIPS endpoints. Blank uses the regional default.
Path-style addressing	Off by default; only relevant behind a custom endpoint.

Editing an existing connection leaves the secret fields blank — empty means "keep the stored value". Clearing the session token field on an edit drops the stored token, which is what you want when it expires.

Sign-in is key-based. AWS SSO, IAM roles and instance profiles are not supported yet.

How it talks to AWS

The renderer cannot reach an arbitrary origin (the desktop app's CSP pins connect-src), and the S3 object API needs PUT, HEAD and DELETE with raw binary bodies. So this extension ships a small Node helper process: it is spawned on demand via the host's managed-process bridge, listens on 127.0.0.1 behind a per-spawn token, and runs the official AWS SDK — so SigV4 signing, multipart upload and retries are the vendor's implementation, not ours. Downloads stream to a temporary file and are renamed on completion, so an interrupted transfer never leaves a half-written file behind.

That helper is why connections are desktop-only — the browser edition has neither a process bridge nor a persistent secret store.

Two settings are available if the defaults clash with something on your machine: objectStorage.aws.sidecarPort (default 47610) and objectStorage.aws.nodePath (default node; Node 18+ required).

For agents and flows

Six capabilities go through the audited gateway: connect, listBuckets, listObjects, statObject, deleteObject (approval-gated) and disconnect.

Transfers are deliberately not exposed here — they take an absolute host path. Use the hub's object-storage.download / object-storage.upload, which resolve the path and gate the upload.

No capability accepts a credential: keys are entered in the connect form and looked up by connection id, so they never appear in a gateway payload.