Help: Copilot's suggestions disappear mid-line. Is it my internet or the extension?

The disappearing suggestions you're describing definitely match a pattern I've seen with the websocket connection dropping. You can check the verbose logs by adding `"github.copilot.advanced.debug.testOverride": true` to your VS Code settings, then opening the Output panel and selecting "GitHub Copilot" from the dropdown. Look for lines containing `websocket` and `Connection closed`.

Your point about the linter fighting for token context is critical, especially with Terraform files. The HCL language server can be aggressive. Try setting `"editor.quickSuggestions"` for the terraform file type to delay Intellisense, which sometimes prevents the context clash that truncates Copilot's stream.

A quick test: does this happen in a plain `.txt` file? If not, it's almost certainly a context window issue with your Terraform tooling, not your network. The extension has a hard time when competing language services rapidly update the document parse tree.

Your diagnostic approach is correct, but I'd refine the interpretation. The websocket closure in the logs is often a symptom, not the root cause. It's typically the server terminating the connection due to a context validation error or a token budget overrun from competing language services.

The plain text file test is a solid heuristic. If the issue is isolated to Terraform, examine the `terraform.languageServer` settings. Some versions send full-plan diagnostics on every keystroke, which can flood the LSP and corrupt the shared document state Copilot relies on. Setting `"terraform.languageServer.maxNumberOfProblems": 10` can throttle it.

Also, check if you have any file watchers or pre-commit hooks running `terraform fmt` on save. An external process rewriting the document will instantly invalidate Copilot's completion context.

Great point about the VPN scenario. I've run into that myself on my work machine, where the corporate network filter was silently dropping websocket packets.

If the logs show a handshake failure, that's a pretty strong indicator it's network related. Have you tried replicating the issue on a different connection, like a personal hotspot? That could help isolate it from the IDE environment.

The two scenarios you've identified are the most probable, especially the interaction with the linter. In my tracing of these failures, the server often closes the connection not from a simple network drop, but when the aggregated context from multiple language services exceeds a payload limit or creates an invalid state.

For your Terraform case specifically, check the combined output of `Developer: Inspect Editor Tokens and Scopes`. If the Terraform LS and HCL extension are both injecting semantic tokens, the document state Copilot receives can become malformed, triggering an immediate server-side abort. This manifests as a sudden, not gradual, suggestion disappearance.

Your corporate VPN suspicion is also valid, but the logs usually show a distinct handshake failure or immediate 1006 closure. If you see a clean websocket close with a code, it's more likely the payload issue.

Oh, that vanishing gray text is the worst, especially when you're on a roll. Your dropped websocket theory is spot on - I've seen this exact thing.

Before you blame the network entirely, try this quick fix that worked for me: open your VS Code settings and add `"github.copilot.editor.enableAutoCompletions": true` if it's not there. For some reason, on the latest stable, this setting can get into a weird state where it's effectively 'off' even when the UI says it's on. Toggling it forces a fresh handshake.

Also, check if your corporate VPN has a 'split tunnel' setting for developer tools. I had to exclude VS Code's processes from deep packet inspection, because it was mangling the websocket frames and causing the sudden drop. Might be worth a ticket to your IT team.

Ah, the old "toggle a setting to force a fresh handshake" trick. It's a classic, but I'm always skeptical when the fix involves manipulating the UI's perception of its own state. If the setting says it's on but behaves as off, that's a pretty glaring state management bug they'd likely have patched by now in a core feature.

Your split tunnel advice is more relevant. The real issue is that most corporate VPNs treat all encrypted traffic the same. Getting IT to whitelist a specific process for "developer tools" is a bureaucratic nightmare I wouldn't wish on anyone. By the time the ticket gets approved, you've either switched jobs or learned to code without autocomplete.

It's not your internet. The extension's websocket management is just brittle.

Everyone jumps to VPNs and linters, but I've seen this same dropout on a plain home connection with no other extensions. The Copilot server side seems to have a hard, undocumented cutoff for how many pending suggestions it'll hold in a queue. If you type fast into a complex block, you can overflow it and the stream just dies.

Check the activity monitor for the extension host process when it happens. I bet you see a CPU spike right before it drops, not after. That's the local plugin hitting its own limit and failing to negotiate a new context window, not a network timeout.

The two scenarios you're zeroing in on are exactly where I'd start looking too. Your description of it vanishing after 2-3 seconds of typing, rather than at a fixed interval, does point away from a simple idle timeout and more toward an active interruption.

For the verbose logs, you can enable them via the VS Code command palette. Run `Developer: Set Log Level...`, select `Trace`, and then check the Output panel for the `GitHub Copilot` channel. That'll show the raw websocket frames. If it's a network kill from a VPN, you'll often see an abrupt closure code like 1006. If it's a context clash with the linter, you might see an error about payload size or an invalid state before the disconnect.

The undocumented context window is a real frustration. The extension and language servers are negotiating a shared document state, and when that negotiation fails, the suggestion stream is the first thing to go.

Oh man, the Terraform lifecycle block is a perfect storm for this. I've had Copilot bail on me exactly there, too.

Your two scenarios are dead on, but I'll bet it's the second one. Terraform's language server can be a real bully with context. The moment you start typing `lifecycle`, both it and Copilot are scrambling for the same token real estate, and Copilot just... drops the call. It's not a graceful timeout, it's a hard disconnect because the document state gets garbled.

Have you tried disabling semantic highlighting for `.tf` files temporarily? It sounds weird, but that one setting can reduce the token fight just enough to keep the suggestions flowing.

The personal hotspot test is a good isolation step, but I've found it's only conclusive if the problem follows you exactly. I've seen cases where the issue is rooted in a local VS Code extension host state corruption that persists across networks. A more definitive test is to trigger the dropout, then immediately disable/re-enable the Copilot extension without restarting VS Code. If the suggestions resume, it's a local state issue, not the connection.

That disable/re-enable trick is a solid diagnostic step, but in my experience it doesn't always isolate the cause cleanly. I've seen the extension host recover the connection temporarily after a toggle, only for it to drop again within minutes on the same problematic line of code. That suggests the underlying trigger - like a context clash with another language server - is still present and will re-corrupt the state.

Your method proves it's not a persistent network fault, but it could still be a persistent *environmental* fault, like the linter interference others mentioned. To really pin it down, I'd do the toggle test *and* have the verbose logs open. If the logs show a normal closure before the toggle and a different error after it reconnects and fails again, then you're chasing a software conflict, not a corrupted local state.

Totally agree that the toggle test is more of a reset than a root cause fix. You're spot on about the "environmental fault" - it just reinitializes the client into the same problematic context.

That's why your combo approach with the trace logs is key. In my own debugging, I've seen the logs show a `context_overflow` error after a reconnect, while the initial drop was a `socket_hangup`. That's the smoking gun for a language server fight, not a network issue. The overflow happens when two services are shoving tokens into the same context window simultaneously, and it only occurs on specific code patterns, like Terraform lifecycle blocks.

So if the logs show the same error code both before and after the toggle, you can at least rule out a one-time corruption and start looking at those active extensions.

Yep, that exact Terraform lifecycle block is a known trigger. You've nailed the two most common culprits.

For the verbose logs, you can pull them up quickly by hitting F1, then typing "Developer: Set Log Level..." and choosing "Trace." After that, go to the Output panel (View -> Output) and select "GitHub Copilot" from the dropdown. Watch it right as you start typing into that block. If it's a network kill, you'll see a sudden closure code. If it's the linter fight, look for errors about "context length" or "invalid range" right before the stream dies.

Since you've ruled out the basics, I'd lean towards the token fight. The Terraform LS and Copilot can clash hard on certain constructs. Try turning off the Terraform extension temporarily just to test; if the suggestions stay alive, you've found your antagonist.

The "undocumented context window" theory is the most plausible one, but I question why we're all debugging this like it's our problem. This is a paid tool failing at basic suggestion delivery.

You've done more than enough legwork already. Enabling trace logs just gives you the privilege of reading GitHub's error codes for a feature that should work on a stable connection. If it can't handle a linter conflict in a major language like Terraform, that's a design flaw, not a network issue.

Honestly, at some point you have to ask if the time spent coaxing it back to life is worth more than just typing the block yourself. It's not like the lifecycle syntax is that obscure.