Object Storage Azure Blob

Adds Azure Blob Storage to the Object Storage extension, so your containers show up alongside every other backend you have connected.

What you can do

• Connect to a storage account with either a connection string or an account plus SAS token
• Browse your containers and blobs from the Object Storage panel
• Download a blob into your workspace, and upload a workspace file back
• Work with a container-scoped SAS, which is treated as a supported setup rather than an error
• Point at Azurite or a sovereign cloud through a custom endpoint

Requirements

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

This is a provider: it owns the Blob client and the "Connect Azure Blob" 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.

Azure calls a bucket a container and an object a blob. The hub speaks bucket/object throughout, so the two vocabularies only meet inside this extension.

Getting started

Open Object Storage in the activity bar → + → Azure Blob Storage.

Two credential shapes, picked with the radio buttons at the top of the form:

Mode	Fields
Connection string	The whole DefaultEndpointsProtocol=…;AccountName=…;AccountKey=… string. Account-wide, so every container is browsable.
Account + SAS token	Storage account name plus the SAS. A SAS is often scoped to a single container — name that container in the Container field, or listing will fail.

A container-scoped SAS is a supported setup, not an error: when the account cannot be listed, the extension probes the named container instead and shows just that one.

The optional custom endpoint covers Azurite and the sovereign clouds.

Editing an existing connection leaves the secret fields blank — empty means "keep the stored value". Switching modes clears the credential the other mode used, so a stale connection string can never silently win over a freshly entered SAS.

How it talks to Azure

The renderer cannot reach an arbitrary origin (the desktop app's CSP pins connect-src), and the Blob 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 Azure SDK — chunked uploads 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.abs.sidecarPort (default 47611) and objectStorage.abs.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: they are entered in the connect form and looked up by connection id, so they never appear in a gateway payload. This matters more for Azure than elsewhere — the kernel's redaction table does not recognise AccountKey= or a SAS sig=, so a connection string in a payload would not be masked in the audit log.