feat: global CSS overlay

[zhangtony239]

Context

Enable overriding of Roo Code’s internal CSS, so that advanced users can fully customize the experience beyond the constraints of the default settings.

i18n review required: I executed i18n entirely using Roo's translation mode, and my personal language skills are not sufficient for manual proofreading, so please assist in checking!

Screenshots

before	after

This example use the following css:

.flex.flex-col.gap-3.shrink-0.mx-5 {
    display: none;
}
div[style*="padding: 0px 15px; user-select: none; border-top: none; overflow-y: auto; margin-bottom: -2px; flex: 0 1 auto; min-height: 0px;"] {
    display: none;
}
.flex.flex-col.items-center.mt-8.gap-2 {
    margin-top: 37vh;
    opacity: 0.2;
}

How to Test

• Run this code.

• Open Settings and click on Edit Global CSS Overlay.

• Press Ctrl + Shift + I to open Developer Tools.

• Use the element picker to select the UI element you want to modify.

• In the Styles panel, inspect the applied CSS classes and identify the most specific/highest-priority class.

• Add a new rule for that class with your desired CSS properties.

• Click Save — changes will take effect immediately.

By the way

I would like to thank #2603 and #2701 for making me realize, more deeply, the challenge of balancing personalization, or as they say, "pleasing everyone." Inspired by SillyTavern, I spent half a day refining this PR.

To be honest, my current feelings are a mixture of joy and a bit of disappointment, especially when I recall how casually #2701 removed the Interface section. For me personally, being able to rework based on an improved upstream is acceptable, but I do feel regretful about Roo's continued stagnation in terms of personalization—at least up until now. As the most popular fork of Cline, I chose Roo because its previous aboutMe was more open than Cline's, not explicitly naming the Claude model. In other words, I chose Roo thinking it might be more personalized, open, and inclusive than Cline.

So, part of me is concerned that this PR might inadvertently lead future contributors to rely on the CSS override feature and think, "Oh, there’s this option to override the CSS, so I don’t need to bother with creating more personalized settings."

However, given the current situation, I still believe this PR is a step forward. At least it’s better than having no personalization settings at all, right?

Get in Touch

Discord: zhangtony239

---

Important

Introduces a global CSS overlay feature for advanced UI customization in Roo Code, with new settings and i18n updates.

• Behavior:
  • Adds global CSS overlay feature allowing users to customize UI by editing CSS in webviewMessageHandler.ts.
  • New settings option "Edit Global CSS Overlay" in InterfaceSettings.tsx.
  • CSS changes apply immediately upon saving.
• Webview Message Handling:
  • Adds openCustomCssFile, closeCustomCssFile, and loadCustomCssContent message types in webviewMessageHandler.ts.
  • Handles opening, closing, and loading custom CSS content.
• UI Components:
  • Adds InterfaceSettings component in InterfaceSettings.tsx for CSS overlay settings.
  • Updates SettingsView.tsx to include interface settings.
• i18n:
  • Updates i18n files for multiple languages to include new strings for CSS overlay feature.
  • Adds translations for error messages and initial comments related to custom CSS.

^{This description was created by for 09b6c5b. You can customize this summary. It will automatically update as commits are pushed.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 09b6c5b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[sachasayan]

Hey @zhangtony239 — I only removed the interface section in #2701 because my PR makes hiding the greeting a default, and would have left it an empty section. I have no issue with it coming back if there's a reason for it to exist.

That said, I think there are two conflicting ideologies here:

• One is that flexibility (customization) is the ultimate good, and everyone's needs should be catered to.
• The other is the ease of use is the ultimate good, and that sensible defaults are the most important thing, with customizability coming at a detriment to ease-of-use.

I tend to think more on the latter side. The interface is already quite complex and can be difficult for new users to navigate, so adding more features and customization options could make it even more frustrating for them. This is also a fast moving codebase and features/structures are changing all the time, so each feature and additional piece of UI represents capital to be managed. It needs testing, support, and be accounted for when other changes happen. This potentially lowers the iteration speed: The bigger your house is, the more work you need to do to maintain it.

With specific respect to customizable stylesheets:

• What happens if a css selector changes, or a piece of UI moves? We can't control the custom stylesheets, so do we just roll with the possibility that we break user setups over and over, week after week?
• What happens if a novice user does something like * {display:none} and blanks out the interface altogether?
  It's okay for these things to happen if we deem them okay, accept the potential instability, or build in escape hatches, but we should ask these questions and go in knowing the risks!

So I understand and support the desire for personalization, but I hope you also understand why my priority is on reducing the learning curve and refining the core interface to work well for the majority of users first, and why those things can sometimes be at odds with customizability.

My three suggestions would be that:

• Prefer sensible defaults over customization first. For something like a greeting message, it doesn't need to be configurable — we probably all agree the greeting message can just be smarter about when it appears. Onboarding UI can usually be moved to the welcome screen and never shown again after it it shown once. This benefits everyone!
• Each instance of proposed customizability be viewed within the lens of tech debt. Consider what happens if the feature changes, if other features change around it, or how it might need to be managed in the future.
• Consider risks. With something like a customizable stylesheet, we either need to catch * {display:none} risks or build escape hatches around them when things go wrong with novice users.

Hope this make sense. Let me know your thoughts.

[zhangtony239]

Hey @sachasayan , thank you for the thoughtful reply — I really appreciate the way you laid out the design principles behind your decision. And to clarify: I don’t mean to hold any grudges over #2701. In fact, @cte already kindly offered to help with restoring the Interface section if needed, so it’s not a big deal at this point. My earlier message may have sounded more emotional than I intended — sorry if it came across that way.

That said, I would still like to clarify a few points regarding the intention behind this PR.

The CSS override feature is clearly marked as a Power user feature – use with caution! and is wrapped in a <fieldset> with proper warnings. It’s not meant for the average user, and it’s specifically not a replacement for more thoughtful, built-in personalization settings. Instead, it's a fallback — a way to make the project more flexible without cluttering the UI or increasing maintenance burden for the team.

In fact, I actually agree with most of what you said about tech debt and user experience. Sensible defaults are crucial, and trying to satisfy every niche through settings can spiral out of control quickly.

But my main concern — and maybe it came through a bit emotionally before — is about discouraging future contributions around personalization. I don’t mean to say you are doing that intentionally, but I do worry about this mindset becoming codified in the project culture. Something like "we already have a CSS override, no need to make the interface more flexible" could easily creep into future PR if we atmosphere this too much, and I think that would be a shame.

And actually, quite the opposite of ideological conflict — this PR was born because I, after going through my last two PRs and seeing the challenges, chose to stand closer to your side: to look for a compromise between personalization and maintainability. That’s why this solution tries to isolate complexity while leaving the core interface untouched. It's not a demand for change — just an invitation to let others explore what’s possible.

I totally understand that you, or others, may not have the bandwidth to push for more personalization right now. That's totally fine. I just hope the door stays open for those who might. We can be pragmatic and still welcoming.

Really appreciate the discussion — looking forward to hearing your thoughts.

[sachasayan]

Building alignment mean we butt heads and step on toes sometimes @zhangtony239, never apologize for being passionate about making OSS better. ✌️😇

But my main concern — and maybe it came through a bit emotionally before — is about discouraging future contributions around personalization. I don’t mean to say you are doing that intentionally, but I do worry about this mindset becoming codified in the project culture. Something like "we already have a CSS override, no need to make the interface more flexible" could easily creep into future PR if we atmosphere this too much, and I think that would be a shame.

It's an interesting idea, and an interesting concern. I share this thought with you, and I'll add on that another concern that if there's a CSS override, people won't feel motivated to contribute their improvements back to the core codebase. In other words, there's the "I already have a CSS override, no need to throw up a PR" dynamic to consider.

Question for you, @zhangtony239 while you were thinking about this: Have you considered a limited number of (supported and curated) preset theme packs, and if so, why was that direction rejected?

[zhangtony239]

Hey @sachasayan,

Thanks again for the thoughtful reply! But as you pointed out before, the potential issues with CSS overrides (like breaking with updates) are exactly why I don't think this will lead to fewer PRs or reduce contributions to the core.

Actually, the reason I still chose to submit this PR after thinking about it is because I believe that by offering this layer of flexibility, it can help expand Roo's appeal and increase its user base. The more people can personalize and experiment with the project, the more they will engage with it. This could actually lead to a more vibrant and active community, and the issue tracker could become a more exciting place with fresh ideas and contributions, even if personalization isn't our top priority right now.

I completely agree with you that we might not have the bandwidth to focus on personalization for the time being. But this approach provides a way for people to explore possibilities and keep the interest of those niche groups (like power users or enthusiasts) engaged. These users can still share ideas and open issues that may inspire us later, or maybe even spark new insights that we hadn't considered.

Ultimately, I see this as a pragmatic way to keep the project inclusive and flexible, without overcomplicating the core features or creating unnecessary maintenance work. So I don’t think we’ll miss out on valuable contributions or inspiration by adding this level of customization — instead, it keeps the door open for innovation while maintaining the stability of the core.

In short, although in the long term, a thematic system should indeed be designed, and the interface settings should be properly improved to be user-friendly, I believe this approach is meaningful in the short term.

Looking forward to hearing your thoughts on this approach!

[sachasayan]

(Hey @zhangtony239, I can tell when you're using ChatGPT for your responses. 😇)

It sounds like we both agree themes are the better long-term path, and there's tech debt risk in pursuing a css injection layer. Let's close this for now and we can revisit shortly when the UI is more stable. I think I've got a decent mid-way solution coming up which should be an acceptable compromise, but if my solution doesn't work for you, ping me and we'll talk about it.