HTTP_PROXY/HTTPS_PROXY no longer honored after 1.60.0

[gouthamve]

Summary

Starting in 1.60.0, the CLI ignores the standard HTTP_PROXY,
HTTPS_PROXY, and NO_PROXY environment variables. Requests go
direct, which breaks usage in environments where outbound traffic
must transit a corporate proxy.

Affected versions

• Broken: 1.60.0
• Last working: 1.59.0

Reproduction

1. Set HTTPS_PROXY=http://localhost:8888 (or any proxy of your choice).
2. Run any CLI command that hits the API, e.g. td today.
3. Observe that the request goes direct to api.todoist.com rather
   than through the configured proxy.

Under 1.59.0, the same setup routes the request through the proxy.

Root cause

This section is all LLM generated and unverified

@doist/todoist-sdk honors HTTP_PROXY / HTTPS_PROXY / NO_PROXY
via undici's EnvHttpProxyAgent, but only on its native-fetch
code path. In transport/fetch-with-retry.js:

if (customFetch) {
    fetchResponse = await customFetch(url, ...)   // no dispatcher
} else {
    const dispatcher = await getDefaultDispatcher() // EnvHttpProxyAgent
    nativeFetchOptions.dispatcher = dispatcher
    ...
}

In #302 (commit 5c692f8), src/lib/api/core.ts started passing a
customFetch to the SDK to attach usage-tracking headers:

  const rawApi = new TodoistApi(token, { customFetch: createTrackedFetch() })

createTrackedFetch in src/lib/usage-tracking.ts wraps
globalThis.fetch directly, with no dispatcher. That silently
bypasses the SDK's EnvHttpProxyAgent, so the proxy env vars are
no longer applied to any SDK-routed request.

The same shape applies to fetchTodoist in oauth.ts and
migrate-auth.ts — those also call globalThis.fetch without a
dispatcher, though in those flows the pre-1.60.0 code was already
calling bare fetch, so it's only a regression on the SDK path.

[doist-release-bot]

🎉 This issue has been resolved in version 1.60.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀