fix(web): hide build pill in narrow sidebars - #9159

💭 Let me look at the file to understand the change being made.

1. browse_code — apps/web/src/components/sidebar/SidebarChrome.tsx

2. git_tools — sidebar-header

💭 I'm noticing a discrepancy between what the grep shows at head versus what the view tool displayed for that same line, so I want to check the actual commit contents directly to figure out which is accurate.

3. git_tools — d937e30..9634f07

4. github_api_read_only — repos/{owner}/{repo}/pulls/{pull_number}/files

💭 The actual change just adds a responsive visibility class to the badge so it shows as inline-flex at that breakpoint. I'm double-checking that the grep result reflects the actual HEAD commit of the branch I cloned, since the repo URL pointed to a specific SHA.

5. git_tools — @[15rem]/sidebar-header

6. git_tools — sidebar-header

💭 I notice main branch applies its responsive-visibility fix to the wordmark span rather than the Badge, which differs from this PR's approach, so I want to check what main's actual badge line looks like to understand the discrepancy.

7. browse_code — apps/web/src/components/sidebar/SidebarChrome.tsx

8. browse_code — In apps/web/src/components/ui/badge.tsx, what are the base classes and variants (including size "sm") for the Badge component? Does the base class include inline-flex or flex display?

💭 I'm working through how tailwind-merge resolves the conflicting display utilities—since hidden and inline-flex are both display classes, the later one wins, so hidden overrides the base at small sizes, then the container query restores inline-flex once the sidebar-header reaches 15rem. Now I'm double-checking that the container query context actually applies correctly given the @container/ setup on the header. I want to verify this holds across sidebar states — collapsed/icon mode, mobile fixed-width sidebar — to make sure the container width thresholds behave as expected in each case. But there's something odd: my earlier grep result showed a version of the file with hidden already present at line 97, yet the direct file view of the same ref showed no such class, which is contradictory. I should re-run the grep against the explicit head commit SHA to resolve which version is actually correct.

9. git_tools — 15rem

10. git_tools — apps/web/src/components/sidebar/SidebarChrome.tsx

💭 That earlier grep result seems stale or mismatched with the current view, so I'll trust the direct file view and diff instead — it looks like only the badge line actually changed. Now I want to check whether the container query threshold at 15rem genuinely affects the sidebar-header width behavior. I should check sidebar.tsx for the width variables and how the sidebar behaves when collapsed, resized, or in mobile sheet mode, since the default width (16rem) versus the 15rem breakpoint is what determines whether the pill shows or clips. I also need to consider whether clipping comes from overflow-hidden rather than the container width itself, and whether container queries measure content-box versus including padding, which could shift the effective threshold. I want to confirm whether the @container/sidebar-header class already existed at the merge base before this PR, since only one line was changed. I'm grepping the merge base to see if the container name is declared and used elsewhere, to figure out if this was already a working pattern or something newly wired up. That's likely pre-existing, not the regression. I should check whether the sidebar header width is actually variable — looking at sidebar.tsx for the resizing logic and --sidebar-width variable across desktop, mobile, and collapsed icon states to see if anything changed there.

11. browse_code — In apps/web/src/components/ui/sidebar.tsx: what are the sidebar width CSS variables (--sidebar-width, --sidebar-width-mobile, icon width), is the sidebar user-resizable (drag handle writing a width variable), and what does SidebarHeader render (classes, data-slot)? Also does the sidebar support collapsible icon mode and how is the header rendered in collapsed state?

12. git_tools — @[[0-9.]+rem]/

💭 I'm checking whether this pattern of hiding the pill below a certain container width is consistent elsewhere, and verifying that the sidebar's minimum resize width (256px/16rem) is always at least 240px, meaning the pill should stay visible even at the smallest resizable size. I'm also considering mobile widths and icon-collapsed mode, where the header wouldn't need the pill anyway since the sidebar slides off. The real question is whether nested padding inside the sidebar container reduces the effective content width below 256px, which would mean I need to trace where SidebarChromeHeader sits relative to the sidebar's inner structure and props.

13. browse_code — Where is SidebarChromeHeader used? Show the Sidebar component invocation(s) in apps/web (props: collapsible, resizable including minWidth/maxWidth/storageKey), and the DOM nesting between [data-slot='sidebar-container'] and SidebarHeader (any wrapper divs with padding or --sidebar-content-inset). Quote the relevant JSX.

💭 I need to check the actual value of THREAD_SIDEBAR_MIN_WIDTH to see if it's below the 240px container query threshold, since that would explain the pill hiding when the sidebar is dragged narrow. I'm also considering whether the header's content box width matches the sidebar width on desktop, and looking at how the trigger and brand elements are laid out to determine if the pill actually gets clipped. Since neither the brand link nor the badge shrink (both have shrink-0), overflow is real when space is tight—especially with the titlebar content offset from Electron's macOS traffic lights eating into available width. The 15rem threshold feels like a reasonable but somewhat arbitrary number given that this offset can vary by platform, so I want to check the actual value of --workspace-titlebar-content-left to see if the fix holds up across different inset sizes.

14. git_tools — workspace-titlebar-content-left|THREAD_SIDEBAR_MIN_WIDTH

💭 I'm working out that between 208px and 240px the pill hides, and above 240px it shows, which seems reasonable. Now I want to verify the clipping is really just from the brand+pill overflow, checking whether the workspace-controls variables are zero in the web version versus Electron macOS. Considering that on Electron macOS the titlebar inset plus the wordmark and "Code" text could push total width past 240px even with the pill hidden, so this threshold fix might not fully resolve clipping in that specific desktop scenario. Since the brand and badge both have shrink-0, they won't compress to compensate. This looks more like an incomplete fix for an edge case rather than a regression from the changed lines themselves, so I want to check the actual titlebar inset values before deciding if it's worth flagging.

15. git_tools — --workspace-controls-left|--workspace-titlebar-control-size|--workspace-titlebar-control-gap

💭 I'm calculating the default titlebar left content width by adding up the padding, icon spacing, and wordmark dimensions (accounting for the SVG viewBox aspect ratio and text sizing), arriving at roughly 110px plus additional margin. Adding the environment pill width for labels like "Production," the total comes out around 181px on the default case and 207px on macOS Electron with traffic lights, both comfortably under the 240px threshold — so the breakpoint change holds up. Now I want to double-check how the Badge component merges its className with tailwind-merge, since the consumer's hidden and responsive inline-flex variant need to correctly override the base inline-flex class. Tailwind-merge groups hidden and inline-flex under the same display category, so since hidden comes later in the merged string, it wins and the base inline-flex gets dropped, while the container-query-scoped inline-flex variant survives since it has a distinct modifier. That should work fine even with named containers like @[15rem]/sidebar-header:. Now I'm second-guessing whether Tailwind v4's container query syntax actually supports this exact arbitrary-value-with-named-container pattern, or if it needs the @min-[] syntax instead. I notice ChangedFilesTree.tsx actually uses @[24rem]/changed-files:inline with a test that only checks the class string appears in markup, not that CSS is actually generated for it. This matches exactly the kind of concern the instructions flagged — if v4 doesn't support this bare @[...] syntax, the class would produce no CSS and the pill could end up permanently hidden. I'm trying to recall how Tailwind v4 handles arbitrary container query variants like @[400px]: versus the named @sm/@min/@max variants, checking whether the upgrade guide confirms support for this bracket syntax. Still tracing variant registration... There's precedent, so that pattern should hold up in production. I'm also checking that hiding the environment pill at narrow widths isn't an accessibility violation—it's decorative-ish info without a tooltip fallback, but likely not a hard rule break. Then I want to confirm whether the @container/sidebar-header setup already existed at the merge base or was newly introduced, so I'm going back to grep the original commit for that container class. Checking mobile behavior next: on narrow viewports the sidebar width calculation still leaves enough room for the pill on something like an iPhone SE, only hiding it below roughly 276px, which seems reasonable. I also want to rule out edge cases like container queries behaving oddly when the sidebar itself is hidden, though that's unlikely to matter here. I also notice the element carries a data-environment-identification="pill" attribute that tests or E2E selectors might depend on, so I should check whether anything consumes that attribute before assuming it's safe to hide.

16. git_tools — data-environment-identification

17. git_tools — @container/sidebar-header

💭 I'm confirming the mobile view still shows the pill correctly, and checking whether the container query setup properly applies inline-size containment to the header so the pill's visibility threshold works as intended across both layouts. The change itself is minor and visual-only, following the existing pattern from ChangedFilesTree, and the class ordering with tailwind-merge should correctly let the container-query variant override the default hidden state without specificity conflicts. I recall that Tailwind sorts variant-prefixed utilities to apply after non-variant ones regardless of alphabetical property order, which is why patterns like hidden md:flex reliably work despite hidden sorting last in the display group internally — the same logic should hold for the container-query variant here, so this pairing is functionally sound. Now I want to confirm inline-flex is actually the correct match for the base state. Since the base badge uses inline-flex, keeping that value for the fallback state does preserve the original layout correctly. But I'm now considering the environment-identification pill: it's meant as a safety signal distinguishing prod from local, and hiding it entirely at narrow widths removes that signal unless there's a fallback like the artwork backdrop mode — which raises the question of whether silently losing that indicator counts as a real UX regression, even though it seems to be the PR's actual intent. I want to trace how the backdrop variant gets resolved based on pill vs. artwork mode, since it looks like pill mode might result in no environment indicator at all when the sidebar is narrow — I should check whether the label appears elsewhere, like in a topbar, or whether truncating the badge instead of hiding it would be a better way to preserve the signal.

18. browse_code — Show apps/web/src/components/SidebarStageBackdrop.tsx: resolveEnvironmentIdentificationPillLabel, resolveSidebarStageBackdropVariant, useEnvironmentStageLabel. Also: is the environment stage label / identification pill rendered anywhere else in the app (other surfaces like topbar or environment switcher) when environmentIdentificationMode === "pill"?

💭 Since the pill labels "Dev" and "Nightly" are so short, I'm checking whether clipping actually happens at the minimum 208px width by estimating the combined width of the titlebar padding, brand text, and pill element—coming out to roughly 161px, well under the minimum. I want to check if macOS Electron overrides the workspace controls offset differently than the web default, since traffic light buttons could shift things. But stepping back, the PR's 15rem threshold exceeds the minimum sidebar width, which makes me wonder if the fix over-hides the pill even in cases where it would actually fit — so maybe the real overflow issue is happening somewhere else, like with the shrink-0 badge overflowing the header rather than the sidebar width itself.

19. git_tools — workspace-controls-left|native-controls-inset|platform

💭 I'm considering whether the desktop Electron app overrides the workspace controls variable differently, but computing the math shows the sidebar header offset comes out the same as on web—so this is likely out of scope for the current fix. I'm also questioning whether the clipping issue reported actually stems from something else entirely, like container query resolution timing when an element is hidden during initial paint, rather than the spacing math itself. Checking the mobile sidebar path confirms the pill and header elements should still fit comfortably on small screens, and I can't find a genuine breaking scenario — just a minor inconsistency in which element gets clipped first, which isn't a real violation of the check's rules. There's a conflict between the instruction to respond with exactly "All clear" and the requirement to use a structured JSON schema with state/title/summary/details fields. Since the JSON format is mandatory, I'll resolve this by using "All clear" as the summary text while keeping the other fields minimal, marking state as success. Let me also verify the container query setup — the header itself acts as the container while the badge is a proper descendant, so that checks out. I should also confirm the tailwind-merge configuration in the cn utility doesn't have custom class groups causing conflicts, and that the Badge component merges its className prop last so overrides apply correctly.

20. browse_code — apps/web/src/components/ui/badge.tsx

21. browse_code — apps/web/src/lib/utils.ts

💭 I'm double-checking that twMerge correctly resolves the conflict since hidden has no modifiers while the container-query variant does, so they don't get treated as conflicting classes with the same modifier scope—this confirms both classes remain distinct and the merge behaves as expected. Everything checks out fine.