attachments --download fails with 404 on Atlassian Cloud (missing version/modificationDate/cacheVersion query params)

[adamtan945]

Describe the bug

confluence attachments <pageId> --download always fails with Error: Request failed with status code 404, even though listing attachments on the same page (without --download) works correctly. Adding --pattern does not help. This happens on Atlassian Cloud.

I traced the root cause to the download URL construction: the Cloud /download/attachments/<pageId>/<filename> endpoint requires the query parameters version, modificationDate, and cacheVersion, which are returned inside each attachment's _links.download field from /wiki/rest/api/content/<pageId>/child/attachment. It looks like the CLI is either omitting or mis-constructing these parameters when building the download request, so the server rejects it with 404.

To Reproduce

Steps to reproduce (against Atlassian Cloud):

1. Pick any Confluence Cloud page that has at least one attachment. Example page ID: 123456789.
2. List attachments — this works fine:

   confluence attachments 123456789
   # Found 1 attachment:
   # 1. example.png (ID: att987654321)
   #    Type: image/png • Size: 387 KB • Version: 1

3. Try to download the same attachment:

   confluence attachments 123456789 --download --dest /tmp/conf-test
   # Error: Request failed with status code 404

4. Narrowing with --pattern reproduces the same failure:

   confluence attachments 123456789 --pattern "*.png" --download --dest /tmp/conf-test
   # Error: Request failed with status code 404

5. Calling the REST API directly with the same credentials succeeds, proving the auth and permissions are fine — the issue is the URL the CLI sends:

   curl -sL -u "$EMAIL:$TOKEN" \
     "https://example.atlassian.net/wiki/rest/api/content/123456789/child/attachment" \
   | jq -r '.results[]._links.download'
   # /download/attachments/123456789/example.png?version=1&modificationDate=1700000000000&cacheVersion=1&api=v2
   
   curl -sL -u "$EMAIL:$TOKEN" \
     -o /tmp/conf-test/example.png \
     "https://example.atlassian.net/wiki/download/attachments/123456789/example.png?version=1&modificationDate=1700000000000&cacheVersion=1&api=v2"
   # → downloads a valid PNG

   Dropping any of version / modificationDate / cacheVersion from that URL causes the server to return 404, which matches the CLI's observed behavior.

Expected behavior

confluence attachments <pageId> --download --dest <dir> should download every attachment on the page to <dir>, using the full download URL (including version, modificationDate, and cacheVersion query parameters) from each attachment's _links.download field.

Screenshots

Not applicable — this is a CLI-only failure.

Environment (please complete the following information):

• OS: macOS 26.4.1 (darwin 25.4.0, arm64)
• Node.js version: v25.9.0
• confluence-cli version: 1.29.0
• Confluence version: Cloud (*.atlassian.net)
• Auth: basic (email + API token), via ~/.confluence-cli/config.json profile

Additional context

• Listing attachments via the CLI works — only --download is broken, so the bug is isolated to the download path / URL construction, not auth or page resolution.
• Reproduced on multiple Atlassian Cloud sites.
• Suggested fix: when downloading, use the _links.download value returned by /rest/api/content/<pageId>/child/attachment verbatim, prefixed with the instance base URL (https://<domain>/wiki), instead of rebuilding the path from the attachment ID or title alone. The query string returned by the API already contains all the parameters the Cloud download endpoint requires.
• Workaround I'm currently using: bypass the CLI and call the REST API + curl -u "$EMAIL:$TOKEN" directly with the full _links.download URL. That works reliably.

Error logs

$ confluence attachments 123456789 --download --dest /tmp/conf-test
Error: Request failed with status code 404

$ confluence attachments 123456789 --pattern "*.png" --download --dest /tmp/conf-test
Error: Request failed with status code 404

Only the message above is emitted — no stack trace is shown by the CLI. If there's a verbose/debug flag that would give a full stack, let me know and I'll re-run and attach it.

[adamtan945]

Update: I dug into the source and the root cause turned out to be different from my original hypothesis. The query parameters (version / modificationDate / cacheVersion) are actually preserved correctly — they're not the problem. The real issue is simpler:

Missing /wiki context path prefix in toAbsoluteUrl.

On Atlassian Cloud, _links.download from the REST API is a path relative to the Confluence context root:

/download/attachments/123456789/example.png?version=1&modificationDate=1700000000000&cacheVersion=1&api=v2

The Cloud context root is /wiki, so the correct URL is https://<domain>/wiki/download/.... But toAbsoluteUrl (lib/confluence-client.js:2072) hands the path straight to buildUrl, which produces https://<domain>/download/... — missing /wiki. Cloud returns 404 for that URL.

Ironically the constructor already computes this.webUrlPrefix = this.apiPath.startsWith('/wiki/') ? '/wiki' : '' on line 38 and uses it correctly in four other places (lines 416, 510, 1356, 1360) when building web UI links. It's just never applied inside toAbsoluteUrl, so downloadAttachment (line 864) and formatAttachment.downloadLink (line 2063) fall through the gap.

Verified by curl'ing the two URLs directly against a live Cloud instance with the same credentials:

URL	Result
https://<domain>/download/attachments/.../?version=... (what the CLI sends)	HTTP 404
https://<domain>/wiki/download/attachments/.../?version=... (with /wiki)	HTTP 200

Server/DC is not affected because webUrlPrefix is an empty string when apiPath doesn't start with /wiki/.

I've opened #99 with a minimal fix (prepend webUrlPrefix inside toAbsoluteUrl with a double-prefix guard) and three new tests. Full suite passes (174/174) and I verified end-to-end that confluence attachments --download now works against a real Cloud instance.

[adamtan945]

Heads up for anyone finding this issue: there's already an open PR for this fix — #93 (opened earlier). I independently opened #99 without noticing it, and I've closed #99 as a duplicate and moved my root cause analysis, end-to-end verification, and regression tests over to #93. The fix is the same one-liner in both cases: prepend webUrlPrefix inside toAbsoluteUrl. Review discussion now lives on #93.