Stream not destroyed on exact-capacity fill

When a chunk's length equals exactly the remaining space (buf.length === space), the code takes the if branch, appends the full chunk, sets total === maxBytes, and then breaks via if (total >= maxBytes) — without calling stream.destroy(). This leaves the underlying Azure SDK stream open until it's garbage-collected, which can hold a live HTTP connection longer than necessary.

The stream.destroy() call in the else branch handles the over-capacity case correctly, but the exact-fill case is missed. Consider consolidating the check:

This is a comment left during a code review.
Path: extensions/azure-blob/src/blob-client.ts
Line: 163-178

Comment:
**Stream not destroyed on exact-capacity fill**

When a chunk's length equals exactly the remaining space (`buf.length === space`), the code takes the `if` branch, appends the full chunk, sets `total === maxBytes`, and then breaks via `if (total >= maxBytes)` — without calling `stream.destroy()`. This leaves the underlying Azure SDK stream open until it's garbage-collected, which can hold a live HTTP connection longer than necessary.

The `stream.destroy()` call in the `else` branch handles the over-capacity case correctly, but the exact-fill case is missed. Consider consolidating the check:

```suggestion
    const buf = Buffer.isBuffer(chunk) ? chunk : Buffer.from(chunk as Uint8Array);
    const space = maxBytes - total;
    if (buf.length <= space) {
      chunks.push(buf);
      total += buf.length;
    } else {
      chunks.push(buf.subarray(0, space));
      total = maxBytes;
      stream.destroy();
      break;
    }
    if (total >= maxBytes) {
      stream.destroy();
      break;
    }
```

How can I resolve this? If you propose a fix, please make it concise.

Empty blobName not validated after trim

readStringParam(..., { required: true }) guards against undefined/null, but a caller passing blobName: "" or blobName: " " would silently reach the Azure SDK with a blank name. The Azure SDK will return a generic 400/404 error rather than the clearer in-tool message you produce elsewhere. A brief guard matches the containerName pattern used just above it:

Then use blobNameTrimmed in place of blobName.trim() for the rest of the function. The TypeBox schema enforces the field is present but doesn't set minLength: 1, so the runtime guard is the only safety net here.

This is a comment left during a code review.
Path: extensions/azure-blob/src/blob-read-tool.ts
Line: 47-54

Comment:
**Empty `blobName` not validated after trim**

`readStringParam(..., { required: true })` guards against `undefined`/`null`, but a caller passing `blobName: ""` or `blobName: "   "` would silently reach the Azure SDK with a blank name. The Azure SDK will return a generic 400/404 error rather than the clearer in-tool message you produce elsewhere. A brief guard matches the `containerName` pattern used just above it:

```suggestion
      const blobNameTrimmed = blobName.trim();
      if (!blobNameTrimmed) {
        return jsonResult({ ok: false, error: "blobName must not be empty." });
      }
```

Then use `blobNameTrimmed` in place of `blobName.trim()` for the rest of the function. The TypeBox schema enforces the field is present but doesn't set `minLength: 1`, so the runtime guard is the only safety net here.

How can I resolve this? If you propose a fix, please make it concise.

Update pnpm-lock.yaml for the new workspace dependencies

Adding @azure/storage-blob here without updating pnpm-lock.yaml leaves the workspace out of sync. On a clean checkout, pnpm install --frozen-lockfile will reject the repo because the new extensions/azure-blob importer and direct dependency entries are missing from the lockfile; the current lockfile has no azure-blob or @azure/storage-blob entry at all.

Useful? React with 👍 / 👎.

Honor maxResults at the Azure API page boundary

For large containers, this still fetches Azure's default first page before stopping locally at maxResults. The SDK's list APIs default to pages of up to 5000 items, so a request like maxResults: 1 can still transfer thousands of blob entries and make the tool slow or hit timeouts. Use .byPage({ maxPageSize: max }) here (and in listContainers) so the server-side work matches the advertised cap.

Useful? React with 👍 / 👎.

Stage azure-blob runtime deps in bundled builds

@azure/storage-blob is introduced as a runtime dependency here, but this package never opts into openclaw.bundle.stageRuntimeDependencies. In packaged OpenClaw installs, bundled plugins are loaded from dist-runtime/extensions or dist/extensions (src/plugins/bundled-dir.ts:15-48), tsdown keeps dependencies external by default (tsdown.config.ts:194-202), and scripts/stage-bundled-plugin-runtime-deps.mjs:34-68 only installs plugin-local node_modules when that flag is true. Because the root package does not ship @azure/storage-blob (package.json:676-706), the Azure Blob plugin will fail to import with MODULE_NOT_FOUND anywhere outside a source checkout.

Useful? React with 👍 / 👎.

Preserve significant whitespace in blob names

blobName is parsed with the default readStringParam behavior and then trimmed again before the read call. Azure blob names are allowed to contain arbitrary characters, so leading/trailing spaces are valid identifiers; in that case azure_blob_list_blobs can surface the exact name from Azure, but azure_blob_read will strip the whitespace and either read the wrong blob or return Blob not found. This makes any container that uses space-padded blob keys unreadable through the new tool.

Useful? React with 👍 / 👎.

Handle malformed Azure connection strings before client creation

If AZURE_STORAGE_CONNECTION_STRING or plugins.entries.azure-blob.config.connectionString contains a typo, BlobServiceClient.fromConnectionString() throws synchronously. Because this call happens before the try blocks in listBlobContainers, listBlobsInContainer, and readBlobBytes, the exception escapes the normal { ok: false, error } path and turns every Azure tool call into an unhandled failure instead of a user-facing config error. Wrapping client construction in the same error normalization used for request failures would keep bad secrets from crashing the tool.

Useful? React with 👍 / 👎.

Preserve significant whitespace in blob-prefix filters

Blob prefixes are matched against blob names verbatim, and Azure blob names can legally contain leading or trailing spaces. Trimming params.prefix here means azure_blob_list_blobs cannot accurately filter blobs like " reports/q1.json" or "foo "; it will query for a different prefix and either miss the target blob or return the wrong set. This is a separate regression from the azure_blob_read name trimming because it breaks discovery as well as reads.

Useful? React with 👍 / 👎.

Distinguish missing containers from missing blobs in reads

When azure_blob_read is pointed at a container that does not exist, Azure returns code: "ContainerNotFound" with HTTP 404. This branch matches any 404 before checking the error code, so the tool reports Blob not found: <container>/<blob> even though the container itself is wrong. That sends users toward the wrong fix and makes bad defaultContainer / containerName config look like a missing blob instead of a missing container.

Useful? React with 👍 / 👎.

Add .github/labeler.yml coverage for azure-blob

AGENTS.md requires new extensions to update .github/labeler.yml and create a matching label. This commit adds extensions/azure-blob/**, but .github/labeler.yml has no extensions: azure-blob rule, so future PRs that only touch this plugin will miss the repo’s extension-label triage/review routing that existing plugins already get.

Useful? React with 👍 / 👎.

Honor explicit accountName/accountKey over env connection strings

If the operator configures plugins.entries.azure-blob.config.accountName/accountKey as documented, but the gateway process also inherits AZURE_STORAGE_CONNECTION_STRING for some other storage account, this branch always picks the env connection string and never reaches shared-key auth. In that multi-Azure-host scenario the plugin will query the wrong account or fail authentication, so the advertised account-name/key setup is effectively unusable unless the user unsets the global env var first.

Useful? React with 👍 / 👎.

Remove the mandatory load-path step from bundled setup docs

This plugin is bundled and auto-discovered from the stock bundled extensions root, so requiring plugins.load.paths here sends normal npm/mac-app users to a repo path they do not have. On those installs, following these instructions makes Azure Blob setup look impossible even though enabling plugins.entries.azure-blob is sufficient, which is a user-facing setup regression for the new feature.

Useful? React with 👍 / 👎.

Stop using stale blob properties to size the download

readBlobBytes() uses the contentLength fetched by getProperties() a few lines earlier to decide how many bytes to request here. If the blob is appended to or overwritten between those two requests—a common case for log/append blobs—n is stale: a blob that grew will be under-read and reported as truncated: false, while a blob that shrank can fail with a spurious range error. This makes reads from actively changing blobs return incomplete or incorrect data even when maxBytes would allow the current contents.

Useful? React with 👍 / 👎.