[Pulsar-Programmer]

Problem

When two or more notices stack above the composer in dark mode, every card gets the 10px dark "seam" shade that is only meant for where the bottom card meets the composer. The upper cards end up with dark bands between them. On the default theme it is faint, but on lighter dark themes (for example Nord from the community theme search) it is clearly visible.

To reproduce: in dark mode, open a thread with messages on a local checkout, switch the checkout to a different branch than the thread's, start typing (the "Branch changed" banner appears), then send /clear (the "fresh session" banner appears above it).

Change

The seam colour in --background-image-composer-seam-above now reads --chat-composer-attached-seam, falling back to the current rgb(0 0 0 / 18%). ComposerBanner.Attachment sets that variable to transparent when another attachment follows it, so only the card touching the composer keeps the shade. Single banners and the banner-to-composer seam look the same as before.

Scope and approval

Small, focused fix for a visual bug: 3 changed lines in ComposerBanner.tsx and index.css, with no behaviour change. It is the same seam effect, applied only where it was meant to be.

Verification

Captured in a dev build (vp run dev, Replay provider) with two real stacked banners (fresh session plus branch changed), before and after the fix, in dark mode.

Nord theme (a community theme installed through Settings → Appearance → Add theme). Before: a dark band under the fresh-session banner. After: the cards join flat.

Default dark theme. The same band exists but is only about 2/255 darker, so it is barely visible:

A pixel diff of the composer area confirms the only changed pixels are the 10 rows above the seam between the two banners (up to 11/255 on Nord, 2/255 on default). The bottom banner's seam into the composer is unchanged. vp run check:changed passes.

Made with Claude Opus 5.5 in Claude Code (T3 Code).

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 33eec53

Macroscope's review found this PR approvable — Removes dark seam bands between stacked composer banners while retaining the shade next to the composer. The change is confined to visual styling, with no effect on data or application behavior.

^{You can add or adjust custom eligibility rules. Learn more.}

[Pulsar-Programmer]

Quick check on intent: I read the shade between stacked banners as accidental. The composer-seam-above comment describes it as the shade where an attached surface meets the composer, and the stack already removes the lower card's top border and radius so cards join edge to edge. If the band was meant as a divider between stacked notices, let me know and I'll close this or replace it with an explicit divider instead.

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

The composer banner seam gradient now uses a configurable color with a fallback. An attached surface hides its seam when another composer banner attachment immediately follows it.

Changes: Composer banner seams

Layer / File(s)	Summary
Seam rendering apps/web/src/index.css, apps/web/src/components/chat/ComposerBanner.tsx	The upper seam gradient uses --chat-composer-attached-seam, with a fallback of rgb(0 0 0 / 18%). An attachment sets the seam to transparent when another attachment immediately follows it.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related PRs

• pingdotgg/t3code#13397: Adds shared composer seam tokens used by the gradient change.

Suggested labels: bugfix

Suggested reviewers: juliusmarminge

Merge Risk: Minimal · up to eaa8b

This change removes unwanted dark bands between stacked composer banners and leaves single-banner seams unchanged. The risk is minimal and no blocking issues were found.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly describes the main change: removing dark seam bands between stacked composer banners.
Description check		The description covers the problem and reproduction steps, explains the change and scope, and reports focused verification with before-and-after screenshots and test results.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: d1aeed2
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 2549be03-d826-4802-8bac-07b37d8a39a5

Commits

Reviewing files that changed from the base of the PR and between 33eec53 and eaa8b6a.

Files selected for processing: 1

• apps/web/src/components/chat/ComposerBanner.tsx

Files skipped from review as they are similar to previous changes: 1

• apps/web/src/components/chat/ComposerBanner.tsx

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

[maria-rcks]

Note

Written by claude-opus-5-5 on behalf of Maria

Takeover update

merged github/main into the branch with a merge commit (eaa8b6a9a6). the only conflict was ComposerBanner.tsx: main's #29018 added --composer-banner-corner-top to the same two joined-card selectors. kept main's lines and this pr's seam-variable line. the pr diff against main is still 2 files, +3/-1.

vp run check:changed passed through blacksmith on the merge commit: format, lint, both knip passes, affected typechecks, react compiler coverage. no review-bot findings were open. the screenshots below were taken on 33eec53, before the merge; the post-merge render is unverified.

---

Verified in a real dev environment

verified unchanged head 33eec5348c77e745cc6da865a45f2221edba0882 on linux with playwright from the repo and /usr/bin/google-chrome.

• reproduced the bands on github/main at 934c7f8d8e7a012aa55be9c0b17498979040fe02 in a separate worktree. ran vp i and a background vp run dev for each revision, stopping main before starting the pr.
• added a real git project through the app and completed a real codex gpt-6.1-sol turn. switched its checkout from main to alternate, typed in the composer, and submitted /clear. no replay provider, mocks, fixtures, or demo data. copied the isolated ui-created state after stopping main for matching captures.
• installed nord through settings. main shows a dark band under the upper notice; the pr removes it while preserving the bottom notice's seam into the composer. also checked default dark and light mode.
• clicked "keep the current session": the upper notice disappears and the single branch notice retains its seam. clicked "restore branch": the repo returns to main and the warning disappears.
• submitted a fresh-session message, then a normal follow-up through codex. both replies arrived. the running server's persisted turns show completed for both, with ordinals 1 and 2 in the new session; the provider session is ready.
• vp run check:changed 511238c3bd8388f26824f59c0ae1a4e70e0ee52d passed through blacksmith after fetching the comparison history: format, lint, both knip passes, affected typechecks, and react compiler coverage. all 29 reported pr checks are successful. no source edits or pushes were needed.

before, main, nord dark:

after, pr, matching composer data and crop:

recorded interactions, dismissing the upper notice, restoring the branch, then arming a single fresh-session notice:

real codex replies and the re-created notice stack:

Not verified

native electron, ios, and android clients; macos/windows rendering; remote relay/tunnel connections; other providers and browsers. this pass exercised the linux web client with real codex turns. no performance claim is made.