Does this issue occur when all extensions are disabled?: No (the crash originates inside the built-in GitHub Copilot Chat 0.48.1 — disabling it is the only way to avoid the error, which trivially "fixes" it but defeats the purpose of the extension)
- VS Code Version: 1.117.0
- OS Version: Local: Windows; Remote: Ubuntu 22.04 (Remote-SSH)
- Copilot Chat Extension: 0.48.1 (built-in, auto-updated on the remote ~7 hours before first failure)
- Copilot SKU:
free_limited_copilot
- Fetcher: Node (expected on vscode-server)
Note on the bisect hint above: GitHub Copilot Chat is now a built-in extension in VS Code 1.117. It is not subject to Help: Start Extension Bisect in the normal way, and the in-product UI exposes no "Install Another Version" affordance for it. That is part of what makes this regression particularly hard for users to recover from — see "Two product-level concerns" at the end.
Summary
After GitHub Copilot Chat auto-updated to 0.48.1 on the remote side of a Remote-SSH workspace, every agent-mode request that enters the tool-calling path crashes with:
TypeError: Cannot read properties of undefined (reading 'bind')
at new Yoe (.../github.copilot-chat-0.48.1/dist/extension.js:2349:2661)
at n._createInstance
at n.createInstance
...
at async ok.runWithToolCalling (.../extension.js:2414:11)
The error is consistent, reproducible on every request, and not user-recoverable through any in-product UI (no version-rollback option is exposed because Copilot Chat is bundled as a built-in extension in VS Code 1.117).
This appears to be a regression in 0.48.1: downgrading to 0.45.1 via "Download Specific Version of VSIX" + manual Install from VSIX on the remote side fully resolves the issue.
Steps to Reproduce
- Connect to a Linux remote via Remote-SSH (this report: Ubuntu 22.04).
- Ensure Copilot Chat 0.48.1 is active on the remote (Extensions panel shows "built-in" and version 0.48.1).
- Open the Copilot Chat panel, select agent mode, choose any model (tested with GPT-4o, GPT-4.1, Claude Sonnet 4 — all crash identically).
- Send any prompt that triggers tool calling, e.g.
read the README in this workspace.
- The request fails with the
bind TypeError shown above.
Ask-mode prompts that do not invoke tools succeed. The four gpt-4o-mini internal calls ([title], [progressMessages]) preceding the failure all succeed in the log, confirming auth and network are healthy. The crash is strictly inside the tool-instantiation phase of runWithToolCalling.
What rules this out
To save investigation time for whoever picks this up:
- Not a model issue. Switched between multiple stable models (GPT-4o, GPT-4.1, Claude Sonnet 4) — all crash identically.
- Not a network / auth issue. Internal
gpt-4o-mini calls for title and progress messages succeed in the same log.
- Not a workspace / cache issue. Reload Window and fresh chat session do not change behavior.
- Not a "local vs cloud" failure. The same models work fine in the local (non-remote) Copilot Chat of the same VS Code installation. The crash is exclusively on the remote side after the auto-update.
- Time-bound to the update. Copilot Chat was working in this exact Remote-SSH setup until ~7 hours before the first failure. The Extensions panel's "Last updated" field for GitHub Copilot Chat 0.48.1 reads "7 hours ago" at the time of writing, which directly establishes the regression entered this environment via auto-update within that window.
Related prior reports
The same Cannot read properties of undefined (reading 'bind') in runWithToolCalling → _createInstance → new <ToolClass>(...) has been reported repeatedly across Copilot Chat versions. The error appears to be a recurring fragility in the tool-instantiation path — a missing defensive check before calling .bind() on what is expected to be a callable dependency. Each release surfaces it under a slightly different trigger condition (specific models, specific tool combinations, specific environments).
Prior reports in microsoft/vscode:
Full log excerpt
2026-05-17 22:24:13.685 [info] Using the Node fetch fetcher.
2026-05-17 22:24:15.713 [info] copilot token sku: free_limited_copilot
2026-05-17 22:24:17.908 [info] ccreq:965b3894.copilotmd | markdown
2026-05-17 22:24:24.797 [info] ccreq:02909ffe.copilotmd | success | gpt-4o-mini-2024-07-18 | 1143ms | [title]
2026-05-17 22:24:25.214 [info] ccreq:d27eb014.copilotmd | success | gpt-4o-mini-2024-07-18 | 1549ms | [progressMessages]
2026-05-17 22:24:25.681 [info] ccreq:1c1c927b.copilotmd | success | gpt-4o-mini-2024-07-18 | 2019ms | [progressMessages]
2026-05-17 22:24:26.731 [error] TypeError: Cannot read properties of undefined (reading 'bind')
at new Yoe (/home/<user>/.vscode-server/extensions/github.copilot-chat-0.48.1/dist/extension.js:2349:2661)
at n._createInstance (.../extension.js:29:2000)
at n.createInstance (.../extension.js:29:1440)
at .../extension.js:2413:3908
at .../extension.js:1802:13429
at Array.forEach (<anonymous>)
at YIe.runOne (.../extension.js:1802:13410)
at async YIe._runLoop (.../extension.js:1802:5981)
at async .../extension.js:1802:4129
at async .../extension.js:6328:2555
at async ok.runWithToolCalling (.../extension.js:2414:11)
at async ok.getResult (.../extension.js:2413:1740)
at async nke.getResult (.../extension.js:2418:10131)
at async px.handleRequest (.../extension.js:2420:4789)
at async L4.getResult (.../extension.js:2430:9146)
at async nw._requestHandler (.../extension.js:7037:1738)
at async i.$invokeAgent (.../extensionHostProcess.js:529:20483)
(The same stack reproduces on every subsequent request, identical line offsets.)
Workaround
For anyone hitting this:
- In the Remote-SSH window, open the Copilot Chat extension page.
- Right-click the extension → "Download specific version of VSIX..." → pick 0.45.1 (or any pre-0.48 version).
- Extensions panel → top-right
⋯ menu → Install from VSIX... → select the downloaded file.
- Reload window. (Optional: if the Extensions panel still shows 0.48.1 active after reload, search
@builtin Copilot Chat, disable the built-in entry on the remote, then reload again.)
- Disable auto-update in Remote Settings to prevent re-upgrade:
Confirmed working on 0.45.1 in the exact environment described above.
Two product-level concerns
Beyond fixing the regression itself, two decisions amplified the user impact significantly and are worth reconsidering:
-
Built-in extension + silent auto-update on the remote side. Built-in status removes the in-product "Install Another Version" affordance and falls outside the normal Extension Bisect flow. Combined with silent auto-update, a user with a working Remote-SSH setup can wake up to a broken environment with no obvious recovery path. For an extension whose recent versions have had repeated tool-init regressions (see linked issues), opting it into the built-in lane while keeping silent auto-updates is a risky combination.
-
Error surfaced to user contains no actionable information. Cannot read properties of undefined (reading 'bind') is shown verbatim with no indication of (a) which tool failed to instantiate, (b) that downgrading is a known mitigation, or (c) that this is a known recurring class of bug. Even a generic "tool initialization failed — try a different model or report at …" would have saved hours of triage. Defensive null-checks at the tool-instantiation site plus a structured error message would significantly reduce the support load this class of failure generates.
Happy to provide more logs, settings dumps, or test specific candidate fixes against this setup if useful.
Does this issue occur when all extensions are disabled?: No (the crash originates inside the built-in GitHub Copilot Chat 0.48.1 — disabling it is the only way to avoid the error, which trivially "fixes" it but defeats the purpose of the extension)
free_limited_copilotSummary
After GitHub Copilot Chat auto-updated to 0.48.1 on the remote side of a Remote-SSH workspace, every agent-mode request that enters the tool-calling path crashes with:
The error is consistent, reproducible on every request, and not user-recoverable through any in-product UI (no version-rollback option is exposed because Copilot Chat is bundled as a built-in extension in VS Code 1.117).
This appears to be a regression in 0.48.1: downgrading to 0.45.1 via "Download Specific Version of VSIX" + manual
Install from VSIXon the remote side fully resolves the issue.Steps to Reproduce
read the README in this workspace.bindTypeError shown above.Ask-mode prompts that do not invoke tools succeed. The four
gpt-4o-miniinternal calls ([title],[progressMessages]) preceding the failure all succeed in the log, confirming auth and network are healthy. The crash is strictly inside the tool-instantiation phase ofrunWithToolCalling.What rules this out
To save investigation time for whoever picks this up:
gpt-4o-minicalls for title and progress messages succeed in the same log.Related prior reports
The same
Cannot read properties of undefined (reading 'bind')inrunWithToolCalling → _createInstance → new <ToolClass>(...)has been reported repeatedly across Copilot Chat versions. The error appears to be a recurring fragility in the tool-instantiation path — a missing defensive check before calling.bind()on what is expected to be a callable dependency. Each release surfaces it under a slightly different trigger condition (specific models, specific tool combinations, specific environments).Prior reports in microsoft/vscode:
Cannot read properties of undefined (reading 'bind')#289752Full log excerpt
(The same stack reproduces on every subsequent request, identical line offsets.)
Workaround
For anyone hitting this:
⋯menu → Install from VSIX... → select the downloaded file.@builtin Copilot Chat, disable the built-in entry on the remote, then reload again.)Confirmed working on 0.45.1 in the exact environment described above.
Two product-level concerns
Beyond fixing the regression itself, two decisions amplified the user impact significantly and are worth reconsidering:
Built-in extension + silent auto-update on the remote side. Built-in status removes the in-product "Install Another Version" affordance and falls outside the normal Extension Bisect flow. Combined with silent auto-update, a user with a working Remote-SSH setup can wake up to a broken environment with no obvious recovery path. For an extension whose recent versions have had repeated tool-init regressions (see linked issues), opting it into the built-in lane while keeping silent auto-updates is a risky combination.
Error surfaced to user contains no actionable information.
Cannot read properties of undefined (reading 'bind')is shown verbatim with no indication of (a) which tool failed to instantiate, (b) that downgrading is a known mitigation, or (c) that this is a known recurring class of bug. Even a generic "tool initialization failed — try a different model or report at …" would have saved hours of triage. Defensive null-checks at the tool-instantiation site plus a structured error message would significantly reduce the support load this class of failure generates.Happy to provide more logs, settings dumps, or test specific candidate fixes against this setup if useful.