Copilot Send button disabled? Check workspace customization settings.

A disabled or inert Send control can be a UI-state problem, an active request, or a workspace customization interaction. First check whether a request is still running and preserve your project state.

Do this first: If you use VS Code 1.112.0 and Copilot Chat 0.40.0 with many parent-repository instructions, compare the settings implicated in issue #303727 in a controlled workspace. Do not change all customization files at once.

What the failure looks like.

The Send action becomes inert in a workspace with many parent-repository customization files while chat.useCustomizationsInParentRepositories is enabled. The cited issue names specific VS Code and Copilot versions.

Why it happens.

Issue #303727 is a version- and configuration-specific VS Code report. It links to #306153 and notes an Insiders patch/milestone; verify your installed stable build before applying an old workaround.

Fix it without losing the task.

Verify no request is still running and record the exact Send-control state: disabled, unresponsive, or hidden.

Capture VS Code and Copilot Chat versions and the relevant workspace customization settings. Avoid copying instruction contents if they contain secrets.

Only if the versions/workspace pattern matches issue #303727, compare behavior with chat.useCustomizationsInParentRepositories changed in a disposable or controlled workspace.

Restore the prior setting after the test and verify Send with a small request. Record the result and any version-specific difference.

What the next AI should receive.

VS Code and Copilot Chat versions, workspace root, count/type of parent instruction files, chat.useCustomizationsInParentRepositories value, whether Send is disabled or inert, and controlled test result.

First safe action

Check that no request is still active, record the VS Code/Copilot versions, and capture the relevant customization setting. If testing the reported setting, change it only for a controlled workspace and then restore or document it.

Evidence boundary

The issue does not show that every disabled Send button has this cause. Its workaround and milestone apply to the reported customization scenario, not unrelated chat errors.

Diagnostic checkpoint

First distinguish an active/in-flight request from an inert composer. Then test the specific customization setting only if the workspace and versions match the report.

How ShardStitch helps.

ShardStitch can preserve the task, files changed, and the failed request state for a fresh session. It cannot re-enable the Send control or determine which extension setting disabled it.

Source trail.

Specific report, checked September 24, 2026: VS Code issue #303727 was opened March 21, 2026 for VS Code 1.112.0 and Copilot Chat 0.40.0. With chat.useCustomizationsInParentRepositories enabled, Send became inert in workspaces with many instruction/customization files. The report is closed, linked to #306153, labeled as patched in Insiders, and assigned milestone 1.114.0. Its documented workaround was setting that customization option to false. Browse the project issue tracker.

FAQ.

Should I disable all VS Code chat customizations when Send is unavailable?

No. First check whether a request is active and whether your configuration matches the specific report. If you test one setting, do it in a controlled workspace and restore it afterward.

Does issue #303727 explain every disabled Copilot Send button?

No. It describes one VS Code/Copilot version and parent-customization configuration. Other causes require their own evidence.

Scope note: This guide is scoped to the configuration and version details in VS Code issue #303727. Recheck the issue and current release notes before relying on its historical workaround.