Fix sidebar resize limit after window growth

[colonelpanic8]

What Changed

• Recompute the thread sidebar maximum width when the browser or Electron window resizes.
• Add focused coverage showing that the allowed sidebar width grows with the viewport.

Why

The sidebar maximum was calculated only during render from the initial window width. If a restored or resized window became wider without another relevant render, the resize rail retained the old cap and could not use the newly available space.

UI Changes

Behavioral only; there are no visual styling changes. In a controlled browser, a stored 900px sidebar correctly clamped to 360px at a 1000px viewport, then returned to 900px when the viewport grew to 1600px, leaving 700px for main content. The collaborative preview screenshot and recording endpoints timed out, so no media is attached.

Validation

• vp test run --project unit src/components/threadSidebarWidth.test.ts (from apps/web)
• vp fmt --check apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• vp lint apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• git diff --check
• Web package typecheck attempted; it is currently blocked by unrelated existing errors in BranchToolbarBranchSelector, ModelPickerContent, PreviewAutomationHosts, and state atom hooks.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (preview capture timed out)
• I included a video for animation/interaction changes (preview recording failed)

---

Note

Low Risk
Layout and resize behavior only in the web app sidebar; no auth, data, or API changes. Risk is localized UI edge cases around persistence vs viewport clamping.

Overview
Fixes the thread sidebar staying capped at the initial window width after the viewport grows, so drag-resize can use newly available space.

AppSidebarLayout drops useSyncExternalStore viewport tracking and passes a resizable config with a livemaxWidth (window.innerWidth), getCssWidth via resolveThreadSidebarCssWidth, and hydrateStoredWidth: false so initial width stays parent-owned. --sidebar-width is set to a CSS min() / max() / calc(100vw - …) expression instead of a fixed pixel value.

Shared Sidebar / SidebarRail now accept maxWidth as a number or getter, optional getCssWidth, and hydrateStoredWidth. On resize end, width is clamped with the live max, --sidebar-width is written through getCssWidth, and persistence runs after clamping. Stored-width hydration calls onResize with the unclamped stored value so a narrow viewport does not overwrite the user’s preference. A window resize listener briefly disables width transitions (skipped during active drags) to avoid glitches when the CSS clamp updates.

Unit tests cover live max clamping, CSS width helpers, and rail commit behavior.

^{Reviewed by Cursor Bugbot for commit 81bd69e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix sidebar resize limit to respect viewport width after window growth

• The sidebar resize limit was not updating when the browser window grew larger, leaving the maximum width stale. This PR fixes that by making maxWidth a live function evaluated at commit time (window.innerWidth) rather than a fixed value.
• SidebarRail now clamps and persists the correct width on stop-resize, and sets --sidebar-width using a dynamic CSS min() expression via the new resolveThreadSidebarCssWidth util.
• A new viewport resize listener in SidebarRail suppresses CSS transitions during viewport-driven width adjustments to avoid visual glitches.
• hydrateStoredWidth=false is set for the thread sidebar so the rail doesn't auto-apply stored width; the parent component handles initial width independently.
• Behavioral Change: stored width hydration now passes the original (unclamped) value to onResize so user preference is preserved even when the viewport temporarily reduces the allowed maximum.

^{Macroscope summarized 81bd69e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 49ba1912-507d-4731-92eb-087ce924b72a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

Bug fix for sidebar resize behavior with limited scope. Changes use standard CSS clamp patterns for responsive width constraints, include unit tests, and are isolated to sidebar width handling. Author has recent commits to these files.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 15fe789. Configure here.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Live sidebar resize limits already shipped in #4655.

[colonelpanic8]

This is not introducing the feature... its fixing the resize limit.

[colonelpanic8]

What Changed

• Recompute the thread sidebar maximum width when the browser or Electron window resizes.
• Add focused coverage showing that the allowed sidebar width grows with the viewport.

Why

The sidebar maximum was calculated only during render from the initial window width. If a restored or resized window became wider without another relevant render, the resize rail retained the old cap and could not use the newly available space.

UI Changes

Behavioral only; there are no visual styling changes. In a controlled browser, a stored 900px sidebar correctly clamped to 360px at a 1000px viewport, then returned to 900px when the viewport grew to 1600px, leaving 700px for main content. The collaborative preview screenshot and recording endpoints timed out, so no media is attached.

Validation

• vp test run --project unit src/components/threadSidebarWidth.test.ts (from apps/web)
• vp fmt --check apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• vp lint apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• git diff --check
• Web package typecheck attempted; it is currently blocked by unrelated existing errors in BranchToolbarBranchSelector, ModelPickerContent, PreviewAutomationHosts, and state atom hooks.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (preview capture timed out)
• I included a video for animation/interaction changes (preview recording failed)

---

Note

Low Risk
Layout and resize behavior only in the web app sidebar; no auth, data, or API changes. Risk is localized UI edge cases around persistence vs viewport clamping.

Overview
Fixes the thread sidebar staying capped at the initial window width after the viewport grows, so drag-resize can use newly available space.

AppSidebarLayout drops useSyncExternalStore viewport tracking and passes a resizable config with a livemaxWidth (window.innerWidth), getCssWidth via resolveThreadSidebarCssWidth, and hydrateStoredWidth: false so initial width stays parent-owned. --sidebar-width is set to a CSS min() / max() / calc(100vw - …) expression instead of a fixed pixel value.

Shared Sidebar / SidebarRail now accept maxWidth as a number or getter, optional getCssWidth, and hydrateStoredWidth. On resize end, width is clamped with the live max, --sidebar-width is written through getCssWidth, and persistence runs after clamping. Stored-width hydration calls onResize with the unclamped stored value so a narrow viewport does not overwrite the user’s preference. A window resize listener briefly disables width transitions (skipped during active drags) to avoid glitches when the CSS clamp updates.

Unit tests cover live max clamping, CSS width helpers, and rail commit behavior.

^{Reviewed by Cursor Bugbot for commit 81bd69e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix sidebar resize limit to respect viewport width after window growth

• The sidebar resize limit was not updating when the browser window grew larger, leaving the maximum width stale. This PR fixes that by making maxWidth a live function evaluated at commit time (window.innerWidth) rather than a fixed value.
• SidebarRail now clamps and persists the correct width on stop-resize, and sets --sidebar-width using a dynamic CSS min() expression via the new resolveThreadSidebarCssWidth util.
• A new viewport resize listener in SidebarRail suppresses CSS transitions during viewport-driven width adjustments to avoid visual glitches.
• hydrateStoredWidth=false is set for the thread sidebar so the rail doesn't auto-apply stored width; the parent component handles initial width independently.
• Behavioral Change: stored width hydration now passes the original (unclamped) value to onResize so user preference is preserved even when the viewport temporarily reduces the allowed maximum.

^{Macroscope summarized 81bd69e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 49ba1912-507d-4731-92eb-087ce924b72a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

Bug fix for sidebar resize behavior with limited scope. Changes use standard CSS clamp patterns for responsive width constraints, include unit tests, and are isolated to sidebar width handling. Author has recent commits to these files.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 15fe789. Configure here.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Live sidebar resize limits already shipped in #4655.

[colonelpanic8]

This is not introducing the feature... its fixing the resize limit.

[colonelpanic8]

What Changed

• Recompute the thread sidebar maximum width when the browser or Electron window resizes.
• Add focused coverage showing that the allowed sidebar width grows with the viewport.

Why

The sidebar maximum was calculated only during render from the initial window width. If a restored or resized window became wider without another relevant render, the resize rail retained the old cap and could not use the newly available space.

UI Changes

Behavioral only; there are no visual styling changes. In a controlled browser, a stored 900px sidebar correctly clamped to 360px at a 1000px viewport, then returned to 900px when the viewport grew to 1600px, leaving 700px for main content. The collaborative preview screenshot and recording endpoints timed out, so no media is attached.

Validation

• vp test run --project unit src/components/threadSidebarWidth.test.ts (from apps/web)
• vp fmt --check apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• vp lint apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• git diff --check
• Web package typecheck attempted; it is currently blocked by unrelated existing errors in BranchToolbarBranchSelector, ModelPickerContent, PreviewAutomationHosts, and state atom hooks.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (preview capture timed out)
• I included a video for animation/interaction changes (preview recording failed)

---

Note

Low Risk
Layout and resize behavior only in the web app sidebar; no auth, data, or API changes. Risk is localized UI edge cases around persistence vs viewport clamping.

Overview
Fixes the thread sidebar staying capped at the initial window width after the viewport grows, so drag-resize can use newly available space.

AppSidebarLayout drops useSyncExternalStore viewport tracking and passes a resizable config with a livemaxWidth (window.innerWidth), getCssWidth via resolveThreadSidebarCssWidth, and hydrateStoredWidth: false so initial width stays parent-owned. --sidebar-width is set to a CSS min() / max() / calc(100vw - …) expression instead of a fixed pixel value.

Shared Sidebar / SidebarRail now accept maxWidth as a number or getter, optional getCssWidth, and hydrateStoredWidth. On resize end, width is clamped with the live max, --sidebar-width is written through getCssWidth, and persistence runs after clamping. Stored-width hydration calls onResize with the unclamped stored value so a narrow viewport does not overwrite the user’s preference. A window resize listener briefly disables width transitions (skipped during active drags) to avoid glitches when the CSS clamp updates.

Unit tests cover live max clamping, CSS width helpers, and rail commit behavior.

^{Reviewed by Cursor Bugbot for commit 81bd69e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix sidebar resize limit to respect viewport width after window growth

• The sidebar resize limit was not updating when the browser window grew larger, leaving the maximum width stale. This PR fixes that by making maxWidth a live function evaluated at commit time (window.innerWidth) rather than a fixed value.
• SidebarRail now clamps and persists the correct width on stop-resize, and sets --sidebar-width using a dynamic CSS min() expression via the new resolveThreadSidebarCssWidth util.
• A new viewport resize listener in SidebarRail suppresses CSS transitions during viewport-driven width adjustments to avoid visual glitches.
• hydrateStoredWidth=false is set for the thread sidebar so the rail doesn't auto-apply stored width; the parent component handles initial width independently.
• Behavioral Change: stored width hydration now passes the original (unclamped) value to onResize so user preference is preserved even when the viewport temporarily reduces the allowed maximum.

^{Macroscope summarized 81bd69e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 49ba1912-507d-4731-92eb-087ce924b72a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

Bug fix for sidebar resize behavior with limited scope. Changes use standard CSS clamp patterns for responsive width constraints, include unit tests, and are isolated to sidebar width handling. Author has recent commits to these files.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 15fe789. Configure here.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Live sidebar resize limits already shipped in #4655.

[colonelpanic8]

This is not introducing the feature... its fixing the resize limit.

[colonelpanic8]

What Changed

• Recompute the thread sidebar maximum width when the browser or Electron window resizes.
• Add focused coverage showing that the allowed sidebar width grows with the viewport.

Why

The sidebar maximum was calculated only during render from the initial window width. If a restored or resized window became wider without another relevant render, the resize rail retained the old cap and could not use the newly available space.

UI Changes

Behavioral only; there are no visual styling changes. In a controlled browser, a stored 900px sidebar correctly clamped to 360px at a 1000px viewport, then returned to 900px when the viewport grew to 1600px, leaving 700px for main content. The collaborative preview screenshot and recording endpoints timed out, so no media is attached.

Validation

• vp test run --project unit src/components/threadSidebarWidth.test.ts (from apps/web)
• vp fmt --check apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• vp lint apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• git diff --check
• Web package typecheck attempted; it is currently blocked by unrelated existing errors in BranchToolbarBranchSelector, ModelPickerContent, PreviewAutomationHosts, and state atom hooks.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (preview capture timed out)
• I included a video for animation/interaction changes (preview recording failed)

---

Note

Low Risk
Layout and resize behavior only in the web app sidebar; no auth, data, or API changes. Risk is localized UI edge cases around persistence vs viewport clamping.

Overview
Fixes the thread sidebar staying capped at the initial window width after the viewport grows, so drag-resize can use newly available space.

AppSidebarLayout drops useSyncExternalStore viewport tracking and passes a resizable config with a livemaxWidth (window.innerWidth), getCssWidth via resolveThreadSidebarCssWidth, and hydrateStoredWidth: false so initial width stays parent-owned. --sidebar-width is set to a CSS min() / max() / calc(100vw - …) expression instead of a fixed pixel value.

Shared Sidebar / SidebarRail now accept maxWidth as a number or getter, optional getCssWidth, and hydrateStoredWidth. On resize end, width is clamped with the live max, --sidebar-width is written through getCssWidth, and persistence runs after clamping. Stored-width hydration calls onResize with the unclamped stored value so a narrow viewport does not overwrite the user’s preference. A window resize listener briefly disables width transitions (skipped during active drags) to avoid glitches when the CSS clamp updates.

Unit tests cover live max clamping, CSS width helpers, and rail commit behavior.

^{Reviewed by Cursor Bugbot for commit 81bd69e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix sidebar resize limit to respect viewport width after window growth

• The sidebar resize limit was not updating when the browser window grew larger, leaving the maximum width stale. This PR fixes that by making maxWidth a live function evaluated at commit time (window.innerWidth) rather than a fixed value.
• SidebarRail now clamps and persists the correct width on stop-resize, and sets --sidebar-width using a dynamic CSS min() expression via the new resolveThreadSidebarCssWidth util.
• A new viewport resize listener in SidebarRail suppresses CSS transitions during viewport-driven width adjustments to avoid visual glitches.
• hydrateStoredWidth=false is set for the thread sidebar so the rail doesn't auto-apply stored width; the parent component handles initial width independently.
• Behavioral Change: stored width hydration now passes the original (unclamped) value to onResize so user preference is preserved even when the viewport temporarily reduces the allowed maximum.

^{Macroscope summarized 81bd69e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 49ba1912-507d-4731-92eb-087ce924b72a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

Bug fix for sidebar resize behavior with limited scope. Changes use standard CSS clamp patterns for responsive width constraints, include unit tests, and are isolated to sidebar width handling. Author has recent commits to these files.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 15fe789. Configure here.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Live sidebar resize limits already shipped in #4655.

[colonelpanic8]

This is not introducing the feature... its fixing the resize limit.

[colonelpanic8]

What Changed

• Recompute the thread sidebar maximum width when the browser or Electron window resizes.
• Add focused coverage showing that the allowed sidebar width grows with the viewport.

Why

The sidebar maximum was calculated only during render from the initial window width. If a restored or resized window became wider without another relevant render, the resize rail retained the old cap and could not use the newly available space.

UI Changes

Behavioral only; there are no visual styling changes. In a controlled browser, a stored 900px sidebar correctly clamped to 360px at a 1000px viewport, then returned to 900px when the viewport grew to 1600px, leaving 700px for main content. The collaborative preview screenshot and recording endpoints timed out, so no media is attached.

Validation

• vp test run --project unit src/components/threadSidebarWidth.test.ts (from apps/web)
• vp fmt --check apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• vp lint apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• git diff --check
• Web package typecheck attempted; it is currently blocked by unrelated existing errors in BranchToolbarBranchSelector, ModelPickerContent, PreviewAutomationHosts, and state atom hooks.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (preview capture timed out)
• I included a video for animation/interaction changes (preview recording failed)

---

Note

Low Risk
Layout and resize behavior only in the web app sidebar; no auth, data, or API changes. Risk is localized UI edge cases around persistence vs viewport clamping.

Overview
Fixes the thread sidebar staying capped at the initial window width after the viewport grows, so drag-resize can use newly available space.

AppSidebarLayout drops useSyncExternalStore viewport tracking and passes a resizable config with a livemaxWidth (window.innerWidth), getCssWidth via resolveThreadSidebarCssWidth, and hydrateStoredWidth: false so initial width stays parent-owned. --sidebar-width is set to a CSS min() / max() / calc(100vw - …) expression instead of a fixed pixel value.

Shared Sidebar / SidebarRail now accept maxWidth as a number or getter, optional getCssWidth, and hydrateStoredWidth. On resize end, width is clamped with the live max, --sidebar-width is written through getCssWidth, and persistence runs after clamping. Stored-width hydration calls onResize with the unclamped stored value so a narrow viewport does not overwrite the user’s preference. A window resize listener briefly disables width transitions (skipped during active drags) to avoid glitches when the CSS clamp updates.

Unit tests cover live max clamping, CSS width helpers, and rail commit behavior.

^{Reviewed by Cursor Bugbot for commit 81bd69e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix sidebar resize limit to respect viewport width after window growth

• The sidebar resize limit was not updating when the browser window grew larger, leaving the maximum width stale. This PR fixes that by making maxWidth a live function evaluated at commit time (window.innerWidth) rather than a fixed value.
• SidebarRail now clamps and persists the correct width on stop-resize, and sets --sidebar-width using a dynamic CSS min() expression via the new resolveThreadSidebarCssWidth util.
• A new viewport resize listener in SidebarRail suppresses CSS transitions during viewport-driven width adjustments to avoid visual glitches.
• hydrateStoredWidth=false is set for the thread sidebar so the rail doesn't auto-apply stored width; the parent component handles initial width independently.
• Behavioral Change: stored width hydration now passes the original (unclamped) value to onResize so user preference is preserved even when the viewport temporarily reduces the allowed maximum.

^{Macroscope summarized 81bd69e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 49ba1912-507d-4731-92eb-087ce924b72a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

Bug fix for sidebar resize behavior with limited scope. Changes use standard CSS clamp patterns for responsive width constraints, include unit tests, and are isolated to sidebar width handling. Author has recent commits to these files.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 15fe789. Configure here.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Live sidebar resize limits already shipped in #4655.

[colonelpanic8]

This is not introducing the feature... its fixing the resize limit.

[colonelpanic8]

What Changed

• Recompute the thread sidebar maximum width when the browser or Electron window resizes.
• Add focused coverage showing that the allowed sidebar width grows with the viewport.

Why

The sidebar maximum was calculated only during render from the initial window width. If a restored or resized window became wider without another relevant render, the resize rail retained the old cap and could not use the newly available space.

UI Changes

Behavioral only; there are no visual styling changes. In a controlled browser, a stored 900px sidebar correctly clamped to 360px at a 1000px viewport, then returned to 900px when the viewport grew to 1600px, leaving 700px for main content. The collaborative preview screenshot and recording endpoints timed out, so no media is attached.

Validation

• vp test run --project unit src/components/threadSidebarWidth.test.ts (from apps/web)
• vp fmt --check apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• vp lint apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• git diff --check
• Web package typecheck attempted; it is currently blocked by unrelated existing errors in BranchToolbarBranchSelector, ModelPickerContent, PreviewAutomationHosts, and state atom hooks.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (preview capture timed out)
• I included a video for animation/interaction changes (preview recording failed)

---

Note

Low Risk
Layout and resize behavior only in the web app sidebar; no auth, data, or API changes. Risk is localized UI edge cases around persistence vs viewport clamping.

Overview
Fixes the thread sidebar staying capped at the initial window width after the viewport grows, so drag-resize can use newly available space.

AppSidebarLayout drops useSyncExternalStore viewport tracking and passes a resizable config with a livemaxWidth (window.innerWidth), getCssWidth via resolveThreadSidebarCssWidth, and hydrateStoredWidth: false so initial width stays parent-owned. --sidebar-width is set to a CSS min() / max() / calc(100vw - …) expression instead of a fixed pixel value.

Shared Sidebar / SidebarRail now accept maxWidth as a number or getter, optional getCssWidth, and hydrateStoredWidth. On resize end, width is clamped with the live max, --sidebar-width is written through getCssWidth, and persistence runs after clamping. Stored-width hydration calls onResize with the unclamped stored value so a narrow viewport does not overwrite the user’s preference. A window resize listener briefly disables width transitions (skipped during active drags) to avoid glitches when the CSS clamp updates.

Unit tests cover live max clamping, CSS width helpers, and rail commit behavior.

^{Reviewed by Cursor Bugbot for commit 81bd69e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix sidebar resize limit to respect viewport width after window growth

• The sidebar resize limit was not updating when the browser window grew larger, leaving the maximum width stale. This PR fixes that by making maxWidth a live function evaluated at commit time (window.innerWidth) rather than a fixed value.
• SidebarRail now clamps and persists the correct width on stop-resize, and sets --sidebar-width using a dynamic CSS min() expression via the new resolveThreadSidebarCssWidth util.
• A new viewport resize listener in SidebarRail suppresses CSS transitions during viewport-driven width adjustments to avoid visual glitches.
• hydrateStoredWidth=false is set for the thread sidebar so the rail doesn't auto-apply stored width; the parent component handles initial width independently.
• Behavioral Change: stored width hydration now passes the original (unclamped) value to onResize so user preference is preserved even when the viewport temporarily reduces the allowed maximum.

^{Macroscope summarized 81bd69e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 49ba1912-507d-4731-92eb-087ce924b72a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

Bug fix for sidebar resize behavior with limited scope. Changes use standard CSS clamp patterns for responsive width constraints, include unit tests, and are isolated to sidebar width handling. Author has recent commits to these files.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 15fe789. Configure here.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Live sidebar resize limits already shipped in #4655.

[colonelpanic8]

This is not introducing the feature... its fixing the resize limit.

[colonelpanic8]

What Changed

• Recompute the thread sidebar maximum width when the browser or Electron window resizes.
• Add focused coverage showing that the allowed sidebar width grows with the viewport.

Why

The sidebar maximum was calculated only during render from the initial window width. If a restored or resized window became wider without another relevant render, the resize rail retained the old cap and could not use the newly available space.

UI Changes

Behavioral only; there are no visual styling changes. In a controlled browser, a stored 900px sidebar correctly clamped to 360px at a 1000px viewport, then returned to 900px when the viewport grew to 1600px, leaving 700px for main content. The collaborative preview screenshot and recording endpoints timed out, so no media is attached.

Validation

• vp test run --project unit src/components/threadSidebarWidth.test.ts (from apps/web)
• vp fmt --check apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• vp lint apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• git diff --check
• Web package typecheck attempted; it is currently blocked by unrelated existing errors in BranchToolbarBranchSelector, ModelPickerContent, PreviewAutomationHosts, and state atom hooks.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (preview capture timed out)
• I included a video for animation/interaction changes (preview recording failed)

---

Note

Low Risk
Layout and resize behavior only in the web app sidebar; no auth, data, or API changes. Risk is localized UI edge cases around persistence vs viewport clamping.

Overview
Fixes the thread sidebar staying capped at the initial window width after the viewport grows, so drag-resize can use newly available space.

AppSidebarLayout drops useSyncExternalStore viewport tracking and passes a resizable config with a livemaxWidth (window.innerWidth), getCssWidth via resolveThreadSidebarCssWidth, and hydrateStoredWidth: false so initial width stays parent-owned. --sidebar-width is set to a CSS min() / max() / calc(100vw - …) expression instead of a fixed pixel value.

Shared Sidebar / SidebarRail now accept maxWidth as a number or getter, optional getCssWidth, and hydrateStoredWidth. On resize end, width is clamped with the live max, --sidebar-width is written through getCssWidth, and persistence runs after clamping. Stored-width hydration calls onResize with the unclamped stored value so a narrow viewport does not overwrite the user’s preference. A window resize listener briefly disables width transitions (skipped during active drags) to avoid glitches when the CSS clamp updates.

Unit tests cover live max clamping, CSS width helpers, and rail commit behavior.

^{Reviewed by Cursor Bugbot for commit 81bd69e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix sidebar resize limit to respect viewport width after window growth

• The sidebar resize limit was not updating when the browser window grew larger, leaving the maximum width stale. This PR fixes that by making maxWidth a live function evaluated at commit time (window.innerWidth) rather than a fixed value.
• SidebarRail now clamps and persists the correct width on stop-resize, and sets --sidebar-width using a dynamic CSS min() expression via the new resolveThreadSidebarCssWidth util.
• A new viewport resize listener in SidebarRail suppresses CSS transitions during viewport-driven width adjustments to avoid visual glitches.
• hydrateStoredWidth=false is set for the thread sidebar so the rail doesn't auto-apply stored width; the parent component handles initial width independently.
• Behavioral Change: stored width hydration now passes the original (unclamped) value to onResize so user preference is preserved even when the viewport temporarily reduces the allowed maximum.

^{Macroscope summarized 81bd69e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 49ba1912-507d-4731-92eb-087ce924b72a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

Bug fix for sidebar resize behavior with limited scope. Changes use standard CSS clamp patterns for responsive width constraints, include unit tests, and are isolated to sidebar width handling. Author has recent commits to these files.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 15fe789. Configure here.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Live sidebar resize limits already shipped in #4655.

[colonelpanic8]

This is not introducing the feature... its fixing the resize limit.

[colonelpanic8]

What Changed

• Recompute the thread sidebar maximum width when the browser or Electron window resizes.
• Add focused coverage showing that the allowed sidebar width grows with the viewport.

Why

The sidebar maximum was calculated only during render from the initial window width. If a restored or resized window became wider without another relevant render, the resize rail retained the old cap and could not use the newly available space.

UI Changes

Behavioral only; there are no visual styling changes. In a controlled browser, a stored 900px sidebar correctly clamped to 360px at a 1000px viewport, then returned to 900px when the viewport grew to 1600px, leaving 700px for main content. The collaborative preview screenshot and recording endpoints timed out, so no media is attached.

Validation

• vp test run --project unit src/components/threadSidebarWidth.test.ts (from apps/web)
• vp fmt --check apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• vp lint apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/threadSidebarWidth.test.ts
• git diff --check
• Web package typecheck attempted; it is currently blocked by unrelated existing errors in BranchToolbarBranchSelector, ModelPickerContent, PreviewAutomationHosts, and state atom hooks.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (preview capture timed out)
• I included a video for animation/interaction changes (preview recording failed)

---

Note

Low Risk
Layout and resize behavior only in the web app sidebar; no auth, data, or API changes. Risk is localized UI edge cases around persistence vs viewport clamping.

Overview
Fixes the thread sidebar staying capped at the initial window width after the viewport grows, so drag-resize can use newly available space.

AppSidebarLayout drops useSyncExternalStore viewport tracking and passes a resizable config with a livemaxWidth (window.innerWidth), getCssWidth via resolveThreadSidebarCssWidth, and hydrateStoredWidth: false so initial width stays parent-owned. --sidebar-width is set to a CSS min() / max() / calc(100vw - …) expression instead of a fixed pixel value.

Shared Sidebar / SidebarRail now accept maxWidth as a number or getter, optional getCssWidth, and hydrateStoredWidth. On resize end, width is clamped with the live max, --sidebar-width is written through getCssWidth, and persistence runs after clamping. Stored-width hydration calls onResize with the unclamped stored value so a narrow viewport does not overwrite the user’s preference. A window resize listener briefly disables width transitions (skipped during active drags) to avoid glitches when the CSS clamp updates.

Unit tests cover live max clamping, CSS width helpers, and rail commit behavior.

^{Reviewed by Cursor Bugbot for commit 81bd69e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix sidebar resize limit to respect viewport width after window growth

• The sidebar resize limit was not updating when the browser window grew larger, leaving the maximum width stale. This PR fixes that by making maxWidth a live function evaluated at commit time (window.innerWidth) rather than a fixed value.
• SidebarRail now clamps and persists the correct width on stop-resize, and sets --sidebar-width using a dynamic CSS min() expression via the new resolveThreadSidebarCssWidth util.
• A new viewport resize listener in SidebarRail suppresses CSS transitions during viewport-driven width adjustments to avoid visual glitches.
• hydrateStoredWidth=false is set for the thread sidebar so the rail doesn't auto-apply stored width; the parent component handles initial width independently.
• Behavioral Change: stored width hydration now passes the original (unclamped) value to onResize so user preference is preserved even when the viewport temporarily reduces the allowed maximum.

^{Macroscope summarized 81bd69e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 49ba1912-507d-4731-92eb-087ce924b72a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

Bug fix for sidebar resize behavior with limited scope. Changes use standard CSS clamp patterns for responsive width constraints, include unit tests, and are isolated to sidebar width handling. Author has recent commits to these files.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 15fe789. Configure here.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Live sidebar resize limits already shipped in #4655.

[colonelpanic8]

This is not introducing the feature... its fixing the resize limit.