When invoking a project-scoped blocks command, either use the resolved account's saved selection or pass --project <tenantId> for that one command without changing saved state. --project applies to CLI commands only, never SDK calls.

Blocks Storage — Configuration

Local snapshot: blocks/storage/ holds a read-only snapshot of the project's storage configs, written by blocks pull --only storage. Read it for context before listing things one by one; check its _meta.tenantId and _meta.pulledAt, and pull again if it's stale or after you change anything. Never edit it to change the project: editing does nothing, so use the commands below. Secret fields in it are ***.

This skill manages the storage configuration record itself — which cloud provider (or local/SFTP storage) a named configuration points at, and the connection details needed to reach it. It does not upload, download, browse, share, version, move, or trash objects; those runtime concerns belong to blocks-data-storage.

CLI-only, no SDK path. There is no @seliseblocks/client method for reading or writing a storage configuration's own fields. Runtime storage calls select an existing record by configurationName. If the user wants to manipulate a file/directory or its access policies, hand off to blocks-data-storage.

Prerequisite: a project is selected (blocks use <tenantId>). If login/project state is unknown, run the blocks-bootstrap skill first.

Command family

All four commands require an impersonated project token — there is no account-token path for this surface, consistent with other project-scoped admin commands (secrets *, data config *, etc.).

blocks storage config list --json
blocks storage config get Default --json
blocks storage config get --name Default --json

list/get never return a secret value. Each secret has a status instead: connectionStringStatus, secretKeyStatus, accessKeyStatus, passwordStatus, sftpSecretKeyStatus, each one of none (not set for this provider), active, locked, archived, missing, unavailable. archived or missing means file calls on that configuration fail until it is deleted and created again with a new secret.

storage config save — fields

save builds its request body from --body/--file (a raw JSON object, spread first) merged with these convenience flags (later, so they win if both are given):

Unset flags are dropped (compact), so they never overwrite fields already present in a --body/--file payload. save is a create-or-update in one command, not two separate verbs — pass --item-id with --update when modifying an existing configuration, omit both to create a new one.

Once a configuration exists, only the four upload settings can change. The provider identity and credentials (--strategy, --connection-string, --access-key, --secret-key, --host, --port, --username, --password, --region-endpoint, --remote-base-path) are fixed at create: blocks-os drops them on an update and still answers success, so the CLI refuses them on --update. To change provider or rotate its credentials, delete the configuration and create it again. An update reads the stored record and carries the upload settings you don't pass, because the server resets any that are left out. A create whose --name is already taken is refused (by the CLI on the live run, and by blocks-os); use --update --item-id <id> instead.

blocks storage config save --name Default --strategy AzureBlob \
  --host mystorageaccount.blob.core.windows.net --region-endpoint eu-west-1 \
  --access-key <key> --secret-key <secret> --dry-run --json
blocks storage config save --name Default --strategy AzureBlob \
  --host mystorageaccount.blob.core.windows.net --region-endpoint eu-west-1 \
  --access-key <key> --secret-key <secret> --yes --json

# Change an existing configuration's upload settings (the only fields an update can change)
blocks storage config save --item-id <id> --update --max-file-size-bytes 10485760 \
  --upload-completion-required-for Public,Private --dry-run --json
blocks storage config save --item-id <id> --update --max-file-size-bytes 10485760 \
  --upload-completion-required-for Public,Private --yes --json

--dry-run before --yes — always

Both mutating commands (save, delete) follow the standard blocks mutation discipline: --dry-run prints what would be sent and returns without mutating anything (an --update dry-run still reads the stored record so it can show the merged body, and reports target: "update"); --yes skips the interactive confirmation prompt and sends the request for real. Omitting both drops into an interactive "Type 'yes' to continue" prompt — not viable in a scripted/agent context, so always pass one or the other explicitly.

blocks storage config delete Default --dry-run --json
blocks storage config delete Default --yes --json

save's dry-run output redacts secret-shaped fields before printing (accessKey, connectionString, password, secretKey become "***") — this redaction is dry-run-preview only, it does not change what's actually sent when you run with --yes, get/list output is redacted the same way (see Gotchas).

Gotchas

• get/list show secret status, not secrets. blocks-os never returns a secret value; the CLI still redacts accessKey/connectionString/password/secretKey/sftpSecretKey if an older server sends one.
• save is upsert, not separate create/update commands. Whether a call creates or updates is determined by --update --item-id, not by a different command name.
• Credentials cannot be rotated in place. An update changes only the upload settings; see above.
• This is provider configuration, not object management. blocks storage config * never touches file bytes, directory hierarchy, versions, trash, sharing, or ACLs. Those belong to blocks-data-storage, using a configurationName that a storage config already defines.
• No positional-or-flag ambiguity trap: get/delete accept the configuration name as either the first positional argument or --name; only one is required, not both.
• Impersonated project token only. Like secrets * and data config *, none of these four commands run against the account token — a project must be selected first (blocks use <tenantId>).

Example trigger prompts

• "Set up Azure Blob storage for this project." → storage config save --strategy AzureBlob ....
• "What storage configurations exist on this project?" → storage config list.
• "Show me the Default storage configuration." → storage config get Default.
• "Rotate the access key on our storage config." → not possible in place: the provider and credentials are fixed once created. Confirm with the user, then storage config delete <name> and storage config save again with the new key.
• "Cap uploads at 10 MB and verify every upload." → storage config save --item-id <id> --update --max-file-size-bytes 10485760 --upload-completion-required-for Public,Private.
• "Switch this project to local storage." → storage config save --strategy <local strategy value> --host ... --port ... (confirm the exact strategy value expected by the project rather than guessing).
• "Delete this storage configuration, we don't use it anymore." → storage config delete <name>.
• "How do I actually upload a file once storage is configured?" → hand off to blocks-data-storage, not this skill.