logs --source deploy returns 404 due to duplicated /api/v1 in request URL

Summary

netlify logs --source deploy fails with 404 Not Found because the CLI sends the historical deploy-log request to a URL containing a duplicated /api/v1 prefix.

This reproduces on two independently linked Netlify sites.

Environment

• Netlify CLI: netlify-cli/26.2.0 darwin-arm64 node-v24.18.0
• Node.js: v24.18.0
• OS: macOS 26.5.2, arm64

Minimal reproduction

1. Link a local directory to a Netlify site that has at least one completed deploy.

2. Run:

   DEBUG=1 netlify logs --source deploy --since 1h
   

3. Observe the request URL and error:

   [debug] → GET https://api.netlify.com/api/v1/api/v1/deploys/<deploy-id>/log
   [debug] ← 404 Not Found
   Error: Failed to fetch deploy logs: 404 Not Found
   

The same result occurs without DEBUG=1; the debug flag only exposes the generated URL.

Expected behavior

The command should return historical deploy logs for the selected/latest ready deploy, as described by netlify logs --help and the CLI command documentation.

Actual behavior

The command always fails with:

Error: Failed to fetch deploy logs: 404 Not Found

Suspected cause

logsCommand passes client.basePath as apiBase:

const apiBase = client.basePath

In a normal authenticated CLI session, this value is already:

https://api.netlify.com/api/v1

fetchDeployHistoricalLogs then appends another /api/v1:

debugFetch(`${apiBase}/api/v1/deploys/${encodeURIComponent(deployId)}/log`, ...)

This produces:

https://api.netlify.com/api/v1/api/v1/deploys/<deploy-id>/log

The likely path-construction fix is to append only /deploys/<deploy-id>/log when apiBase is client.basePath.

Additional observation

I also tested the presumed corrected URL directly with the same authenticated token and deploy IDs:

GET https://api.netlify.com/api/v1/deploys/<deploy-id>/log

That request also returned 404 Not Found on both sites. In addition, the public Netlify OpenAPI specification does not appear to expose a GET endpoint for historical deploy logs (it documents POST /builds/{build_id}/log, but not a deploy-log retrieval endpoint).

So there may be two separate issues to verify:

1. The duplicated /api/v1 in the CLI URL construction.
2. Whether /deploys/{deploy_id}/log is the correct and currently available backend endpoint for historical deploy-log retrieval.

Regression/testing note

The historical deploy-log path was added as part of the unified logs command. The current integration tests appear to cover migration from the deprecated logs:deploy command, but not an authenticated historical deploy-log HTTP request, which may explain why the malformed URL was not caught.

netlify logs --source deploy --follow takes the WebSocket path instead and does not hit this HTTP 404, although it naturally requires an active build.

Locate logsCommand and fetchDeployHistoricalLogs, then trace how client.basePath is passed into the historical deploy-log request. Verify whether the corrected endpoint is available and add coverage for the authenticated HTTP request alongside the existing unified logs integration tests; done means deploy logs work or the unsupported endpoint is clearly identified.