[BUG] Grey Screen

[imaginationchristmas]

Problem (one or two sentences)

There is a grey screen that appears once in the Roo code panel. When working, it just goes to a grey screen and I am not sure why. I am needing to close out of VScode and come back in to resolve and continue working.

Context (who is affected and when)

It happens just running normally. During a session with Claude, it just appears and I can not see the dialog.

Reproduction steps

Macbook Pro 14"
Running PPQ.ai API

Expected result

Should just not show a grey screen (?)

Actual result

Grey screen appears while working

Variations tried (optional)

No response

App Version

3.51.1

API Provider (optional)

OpenAI Compatible

Model Used (optional)

Claude Sonnet 4.6 and others

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Root cause analysis:

The grey screen is most likely caused by the webview failing to receive (or losing) its initial state hydration from the extension host. In App.tsx:219-221, when didHydrateState is false, the component returns null -- rendering absolutely nothing, which appears as a blank grey panel. This can happen when:

1. The extension host restarts or becomes temporarily unresponsive during a session
2. A race condition causes the webviewDidLaunch message to be sent before the extension is ready to respond
3. The webview is moved/reloaded by VS Code (e.g., panel rearrangement) and the state message never arrives

Currently there is no retry mechanism or visual feedback when in this state -- the user just sees grey.

Proposed fix:

1. Add a loading/retry UI in App.tsx -- Instead of returning null when !didHydrateState, show a lightweight loading spinner so the user knows the panel is alive
2. Add a retry mechanism in ExtensionStateContext.tsx -- If the state has not been hydrated within a reasonable timeout (e.g., 5 seconds), automatically re-send the webviewDidLaunch message to request state again. This handles cases where the initial message was lost or the extension host was not ready
3. Add a "Retry" button -- After multiple failed attempts (e.g., 3 retries), show a visible "Retry Connection" button so the user can manually trigger reconnection without restarting VS Code

This approach addresses the symptom (grey screen with no feedback) and the root cause (lost state messages with no recovery path).

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[mini2s]

Problem (one or two sentences)

There is a grey screen that appears once in the Roo code panel. When working, it just goes to a grey screen and I am not sure why. I am needing to close out of VScode and come back in to resolve and continue working.

### Context (who is affected and when) It happens just running normally. During a session with Claude, it just appears and I can not see the dialog.

Reproduction steps

Macbook Pro 14" Running PPQ.ai API

Expected result

Should just not show a grey screen (?)

Actual result

Grey screen appears while working

Variations tried (optional)

No response

App Version

3.51.1

API Provider (optional)

OpenAI Compatible

Model Used (optional)

Claude Sonnet 4.6 and others

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

You can try costrict (support gemini-cli、claude code) or cline

[CyberT33N]

Hey, thank you very much for the tip about Costrict. It’s a very underrated command.

Yes, in its current state, Roo Code is no longer usable because it keeps greying out continuously, and then I have to reload the window for the sessions.

Of course, I can reload it via the Command Palette or restart it manually, but that does not change the fact that I then have to continue the progress again in the chat window.

With parallel file editing, all progress is always lost.

This problem does not seem to have existed for only a few weeks. I believe it has actually been around for over a year or so, and they have not fixed it so far.

I am going to test Co-Strict now. If it works there, that would mean, conversely, that this is definitely a problem that can be fixed. I have not looked into the topic very deeply, but in the threads it was always described as a problem they supposedly cannot fix because it has to do with the VS Code extension architecture and how the session behaves when it lasts too long, or something along those lines.

However, since Co-Strict is a fork of Roo Code, if the issue does not occur there, that would in turn mean that it is in fact solvable and that it is a bug.

[CyberT33N]

Also, it definitely does not happen with costrict. They have fixed the issue there. So may worth to compare the code difference there

@roomote

https://github.com/zgsm-ai/costrict

[roomote-v0]

I've seen your comment about costrict having fixed the grey screen issue. I'll compare the relevant code differences and work on a fix. I'll open a PR to share progress.

[roomote-v0]

Opened a PR with my attempt at addressing this: #12263

Based on comparing with the costrict fork, the key difference was that they show a LoadingView with a spinner instead of returning null (which produces the blank grey panel). This PR takes the same approach and also adds automatic retry logic for the webviewDidLaunch message plus a manual "Retry Connection" button as a fallback. Feedback welcome!

[CyberT33N]

Nvm costrict also crashed for me with grey screen :/

[rkfg]

Could it be because of your VRAM exhaustion? I run Qwen 3.6 35B A3B APEX, the Quality version, it fills up almost all of my VRAM (30.9 GB out of 32) and there's really not much left. This gray window issue usually happens to me with very long chats. Also, when it happens try opening Electron devtools (they're in VSC menu) and inspecting the gray goo, need to find out what it is. I'll do the same when it happens the next time.

[CyberT33N]

Hey, thank you very much for the tip.

No, it is not due to my hardware. I have also seen posts from people who have better machines than I do. I have 64 GB of RAM and a graphics card with 32 GB of VRAM, and I am not running anything locally at all. I only have VS Code open, so I am not hitting any limits there.

I also have the same problem on Windows on my other machine. Including the fact that other people with even better hardware are reporting the same issues, this suggests that it is due to something internal in Roo Code / Chromium?.

I do not work with other extensions. In theory, though, if this were really the issue, then all extensions would have this problem, such as GitHub Copilot, Cline, and everything else, if it were the same kind of issue related to VS Code extensions running iteratively over a longer period of time.

I have not looked into the topic very much, because to fix the problem, you would either have to maintain a custom fork yourself and then work with that, or create a pull request. But it feels like the Roo Code team is not really accepting any more anyway, because everything is flooded with pull requests. That also makes the likelihood of getting something integrated very low.

But the tip about DevTools is a good idea. I never looked into DevTools each time. I had only ever tried to somehow get rid of the gray window in DevTools, but of course I never actually tried looking at the console or anything like that.

I’m seeing this issue with longer chats as well, although “longer chats” isn’t really the right term here.

I usually just have two or three windows open, and it keeps running. Then at some point, it crashes. So it’s not like I reach 100% and then context compression kicks in and I start over from the beginning.

It’s more that I start new chat windows, for example, and then at some point it just happens. That means there must be something internal causing it, for whatever reason.

Yes, I think we really need to look at this properly from an architectural perspective.

What the AI is saying here, or the bot, is ultimately the same thing that has already been suggested in other Reddit posts and similar discussions: that we should simply integrate a retry button.

The problem is how practical that actually is. For example, if five files are being recreated in parallel and the error occurs on the first file, and we then reload the application, the applied Git diffs would probably be lost as well.

I think we would be building on technical debt if we added a retry button here. So, in my view, we should rather find the underlying root cause of the problem, where it comes from, and what is causing it.

The much more interesting question is: how can this bug have existed since 2025 and still not be resolved?

I mean, I have not worked with Roo Code for the last two years, and I have only started using it again for the past one or two months. Since then, I have been getting these grey background errors continuously, 24/7.

Given that I am clearly not the only one experiencing this, I really have to ask how this app can even be used here since 2025 with the grey background issue.

Why is this problem not being prioritized more highly and actively worked on to be fixed? I do not understand it.

#5601

[CyberT33N]

I think this is the issue here, because I always work in at least two windows, or even more, and I work in them over a longer period of time.

Also, CoStrict has an Auto Cleanup option for Task History under the Checkpoints section. I strongly assume that this may have been integrated because they are experiencing exactly the same issues, and that may be why it was added.

The problem is that I only installed CoStrict today, and in the Global Storage folder I only have around 10 tasks or so, not even that many. So I do not assume it has anything to do with the quantity.

I assume it is the combination of open windows, including how long the conversations are, because some conversation files are around 2 MB for me. I think it simply adds up with the open windows and whatever is loaded in parallel, and that ends up overloading the internal memory window.

@roomote

#5601 (comment)

[rkfg]

Thank you for your observations and the link, looks like it's a "simple" RAM OOM, not GPU related! Not even Roo-exclusive and happens to the other extensions as well. It should probably be solved or worked around at VSC level. Though honestly a chat extension shouldn't exhaust gigabytes of RAM even with long chats. There has to be some room for optimization.