fix: Windows Node.js globalThis.fetch undefined 启动报错

[deep-innovator]

在 Windows 环境下的 Node.js 中，不会自动将 fetch 挂载到 globalThis， 导致启动 opencli daemon 时报错：

TypeError: Cannot read properties of undefined (reading 'bind')

问题原因

const nativeFetch = globalThis.fetch.bind(globalThis); Windows 上 globalThis.fetch 为 undefined

修复方案

替换为兼容异步加载 Node 内置 fetch 的写法：

const nativeFetch = async () => {
const { fetch } = await import('node:util');
return fetch;
};

验证环境

• Node.js v20.20.2
• Windows 10
• 已正常启动 opencli daemon 并使用

Description

Related issue:

Type of Change

• 🐛 Bug fix
• ✨ New feature
• 🌐 New site adapter
• 📝 Documentation
• ♻️ Refactor
• 🔧 CI / build / tooling

Checklist

• I ran the checks relevant to this PR
• I updated tests or docs if needed
• I included output or screenshots when useful

Documentation (if adding/modifying an adapter)

• Added doc page under docs/adapters/ (if new adapter)
• Updated docs/adapters/index.md table (if new adapter)
• Updated sidebar in docs/.vitepress/config.mts (if new adapter)
• Updated README.md / README.zh-CN.md when command discoverability changed
• Used positional args for the command's primary subject unless a named flag is clearly better
• Normalized expected adapter failures to CliError subclasses instead of raw Error

Screenshots / Output

[Astro-Han]

This patch breaks the no-proxy path.

nativeFetch used to be the fetch implementation itself:

const nativeFetch = globalThis.fetch.bind(globalThis);

That matches the later call site:

return nativeFetch(input, init);

After this change, nativeFetch is no longer the fetch implementation. It is an async function that tries to load one:

const nativeFetch = async () => {
  const { fetch } = await import('node:util');
  return fetch;
};

Two issues here:

1. node:util does not export fetch on current Node versions, so this resolves to undefined.
2. fetchWithNodeNetwork() still calls nativeFetch(input, init) as if nativeFetch were the request function. It now returns a fetch function, or undefined, instead of returning a Response.

So the no-proxy branch no longer returns a Response. This changes the failure mode, but does not fix it.

The fix needs to keep the original contract intact: nativeFetch still needs to behave like (input, init) => Promise<Response>, while also handling environments where globalThis.fetch is missing at module load time.

[deep-innovator]

Thanks for the review. The original implementation would throw errors on Windows 10 with current Node.js versions because globalThis.fetch is not available at module load time. Could you help fix this issue while keeping the no-proxy path working correctly?

…

---- 回复的原邮件 ---- | 发件人 | ***@***.***> | | 日期 | 2026年04月07日 00:06 | | 收件人 | ***@***.***> | | 抄送至 | ***@***.***>***@***.***> | | 主题 | Re: [jackwener/opencli] fix: Windows Node.js globalThis.fetch undefined 启动报错 (PR #833) | @Astro-Han commented on this pull request. This patch breaks the no-proxy path. nativeFetch used to be the fetch implementation itself: constnativeFetch=globalThis.fetch.bind(globalThis); That matches the later call site: returnnativeFetch(input,init); After this change, nativeFetch is no longer the fetch implementation. It is an async function that tries to load one: constnativeFetch=async()=>{const{ fetch }=awaitimport('node:util');returnfetch;}; Two issues here: node:util does not export fetch on current Node versions, so this resolves to undefined. fetchWithNodeNetwork() still calls nativeFetch(input, init) as if nativeFetch were the request function. It now returns a fetch function, or undefined, instead of returning a Response. So the no-proxy branch no longer returns a Response. This changes the failure mode, but does not fix it. The fix needs to keep the original contract intact: nativeFetch still needs to behave like (input, init) => Promise<Response>, while also handling environments where globalThis.fetch is missing at module load time. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Astro-Han]

Thanks, that matches what I’m seeing. The Windows issue looks real, but the current fallback changes what nativeFetch is.

I think the least invasive fix is to keep nativeFetch as the request function itself, and only change where it comes from:

const nativeFetch: typeof globalThis.fetch = globalThis.fetch
  ? globalThis.fetch.bind(globalThis)
  : ((input: RequestInfo | URL, init?: RequestInit) => (
      undiciFetch(
        input as Parameters<typeof undiciFetch>[0],
        init as Parameters<typeof undiciFetch>[1],
      ) as unknown as Promise<Response>
    ));

That keeps this call site valid:

return nativeFetch(input, init);

So the no-proxy path still behaves the same:

• use globalThis.fetch when it exists
• fall back to undiciFetch when it does not

I would avoid a lazy lookup like (globalThis.fetch ?? undiciFetch)(...) inside the wrapper, because after installNodeNetwork() runs, globalThis.fetch points back to this wrapper.

If helpful, I can also sketch the regression test for the case where globalThis.fetch is missing at module load time.

[Astro-Han]

If you want to keep this in the current PR, that makes sense.

If it saves time, I can also send a small PR with the fallback change and a regression test for the case where globalThis.fetch is missing at module load time.

Either way works for me.

[deep-innovator]

Thanks! I'll fix it in this PR and keep the no-proxy path working properly.

…

---- 回复的原邮件 ---- | 发件人 | ***@***.***> | | 日期 | 2026年04月07日 00:35 | | 收件人 | ***@***.***> | | 抄送至 | ***@***.***>***@***.***> | | 主题 | Re: [jackwener/opencli] fix: Windows Node.js globalThis.fetch undefined 启动报错 (PR #833) | Astro-Han left a comment (jackwener/opencli#833) If you want to keep this in the current PR, that makes sense. If it saves time, I can also send a small PR with the fallback change and a regression test for the case where globalThis.fetch is missing at module load time. Either way works for me. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>