fix(web): keep image preview above sidebar control - #8811

💭 I'm noticing the change bumps the expanded image dialog overlay from z-50 to z-[60], so I want to check how that compares with other z-index values used elsewhere in the codebase for consistency.

1. browse_code — apps/web/src/components/chat/ExpandedImageDialog.tsx

2. git_tools — z-[?[0-9]+]?

💭 I'm checking the z-index scale across the app—dialogs at z-50, chat composer at z-70, menus and tooltips higher up—to see where z-[60] for the expanded image overlay fits, since it needs to sit above dialogs but below the composer. This seems tied to a fix ensuring the expanded image doesn't get hidden behind other layered elements.

3. browse_code — apps/web/src/components/chat/ChatComposer.tsx

4. git_tools — ExpandedImageDialog

💭 I'm checking where the ExpandedImageDialog is rendered within ChatView, since if it's nested inside a parent with its own stacking context, the fixed positioning with high z-index won't actually escape that ancestor's stacking context. I need to look at the surrounding component structure around that render location to confirm.

5. browse_code — apps/web/src/components/ChatView.tsx

💭 The grep result pointing to line 7318 for ExpandedImageDialog doesn't match what I'm seeing there, which shows environmentId instead—so I need to search again to find the actual location.

6. git_tools — <ExpandedImageDialog

7. git_tools — ExpandedImageDialog

💭 I'm checking whether the dialog's root div creates its own stacking context, since if it does, bumping z-index from 50 to 60 might only work within that context and not actually resolve overlap with sibling elements like other dialogs or sheets outside the ChatView tree.

8. git_tools — z-index|z-[|--z-

9. git_tools — apps/web/src/components/chat/ExpandedImageDialog.tsx

💭 The commit message explains this fixes the image preview being hidden behind the sidebar control, which sits at z-50. I'm checking whether bumping the z-index to 60 keeps things consistent with the rest of the codebase, which mixes z-50 and z-100 conventions. The bigger question is whether z-60 could now push the expanded image above things it shouldn't, like real modal dialogs which also use z-50 — but since stacking context depends on where each component is portaled or nested in the DOM tree, I need to trace whether ExpandedImageDialog, rendered inside ChatView, actually competes with the sidebar's fixed z-50 element in the same stacking context for the fix to matter at all.

10. browse_code — apps/web/src/components/AppSidebarLayout.tsx

11. git_tools — data-chat-view|return (\n

💭 I'm tracing the DOM structure since SidebarControl sits as a sibling to children under SidebarProvider, while ChatView is nested inside those children. For the image dialog's z-60 to actually render above SidebarControl's z-50, I need to check whether any wrapper around ChatView—like SidebarInset—creates its own stacking context through relative positioning, isolation, or transforms that would trap the dialog's z-index locally.

12. git_tools — SidebarInset|function SidebarProvider|isolate

13. git_tools — expandedImage

💭 I need to find the root element of ChatViewContent to check its stacking context. I recall spotting a z-50 absolute positioned div around line 6978, so I'll look further down near 7100 to locate the actual outermost container.

14. browse_code — apps/web/src/components/ChatView.tsx

💭 I'm checking whether the root div's relative class creates a stacking context—it doesn't without z-index, so the fixed z-[60] dialog element should stack relative to the root context, provided no intermediate ancestor creates its own stacking context. I'm verifying that the dialog is a direct sibling within that root div's children. Now I need to check the ancestor chain above the root div—whether SidebarInset or the SidebarProvider wrapper introduces a stacking context, and whether the surface-grain class applies any filter, backdrop-filter, or isolation property that would trap the fixed element. Overflow-hidden shouldn't clip a fixed descendant since the ancestor isn't transformed, so that's not the issue—I need to look at surface-grain's CSS definition next.

15. git_tools — surface-grain

16. browse_code — apps/web/src/components/ui/sidebar.tsx

💭 No stacking context issues seem to block this, so z-[60] should beat the sidebar's z-50. I'm noting the codebase mixes arbitrary and plain z-index classes, but that's just a harmless stylistic inconsistency, not worth flagging. I should also check whether bumping this value causes any behavioral side effects. Also worth checking: could the expanded image overlay now render above modal dialogs like Dialog/AlertDialog/Sheet, which portal to the body at z-50? Since image expansion is only triggered from the chat timeline, which becomes inert while a modal is open, this seems like low risk. I still want to verify the ChatComposer's command drawer, which sits at z-[70] and portals separately, to make sure there's no conflict there. Checking other z-50 elements that might now be unintentionally overlapped: the browser device toolbar, quit hold overlay, theme editor panel, and workspace panel controls all seem fine or even improved since the image preview being higher makes sense given it's launched from chat. The one case worth flagging is the workspace controls in the titlebar at z-50, which previously could stack above the image preview but now would sit underneath it. Now I realize the overlay marks itself as no-drag across the whole viewport, which previously wasn't an issue since the sidebar control sat later in the DOM at equal z-index and painted above it, making the toggle button clickable through the overlay. With the new higher z-index, the overlay now intercepts that click entirely, which matches the intended fix but means the sidebar toggle is no longer reachable while the preview is open.

17. browse_code — Is there any documented z-index layering convention or overlay stacking scale (e.g. in AGENTS.md, docs, or comments) for the web app in apps/web? What layers are defined (dialog 50, toast 100, popover 130, tooltip 140) and is there guidance about using arbitrary z-index values like z-[60] for fullscreen overlays? Also, is there a shared fullscreen overlay/lightbox primitive in apps/web/src/components/ui that ExpandedImageDialog should use?

💭 The z-index bump is a magic number but it fixes the real overlap with the sidebar control, even without a centralized scale. I want to check for regressions though—if the expanded image can be triggered from within a Dialog (like PullRequestThreadDialog or MessagesTimeline), which is also portaled at a high z-index, this change might now render the image above that dialog unexpectedly. Since ExpandedImageDialog isn't portaled and sits as a sibling in ChatView, I need to verify no ancestor has transform/filter/contain that would break the fixed positioning—overflow-hidden on the root should be fine. Other overlay layers like toasts (z-100) and menus (z-130) still sit comfortably above this, so those remain unaffected, and I don't see any conflicts with the sidebar control's clickability being briefly covered. I'm also wondering whether other z-50 dialogs from the shared ui/dialog component have this same sidebar-overlap issue, which would suggest a broader inconsistency in the z-index scheme rather than an isolated fix. Other transient actions like the download toast sit at a higher z-index anyway, so no conflict there. I don't see any findings worth flagging, so I'll conclude with "All clear," formatted to satisfy the required JSON output schema.