fix(ux): spamming cmd + , no longer stack opening settings

[jamesx0416]

What Changed

Replaced repeated settings-route pushes from the desktop menu action when the current route is already under /settings.

Why

Pressing Cmd+, or using the macOS Settings menu item while already in settings could push duplicate settings entries onto browser history. That forced users to press Escape or Back multiple times to leave settings. Replacing the current history entry for repeated settings opens keeps the escape/back path to a single step.

UI Changes

No visual UI changes. This only changes settings navigation history behavior.

Before:

Screen.Recording.2026-05-19.at.5.17.24.pm.mp4

After:

Screen.Recording.2026-05-19.at.5.18.13.pm.mp4

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

Low Risk
Single-file navigation tweak with no auth, data, or API impact.

Overview
Fixes duplicate browser history when the desktop app fires open-settings (e.g. Cmd+, or the macOS Settings menu) while the user is already under /settings.

In AppSidebarLayout, the handler still navigates to /settings, but passes replace: true when the current pathname already starts with /settings. A pathnameRef keeps the latest route inside the stable onMenuAction callback so repeated opens do not push another history entry.

No visible UI change—only navigation/back behavior.

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

Note

Replace history entry instead of stacking when navigating to settings

In AppSidebarLayout.tsx, the open-settings menu action now calls navigate with replace: true when the current pathname already starts with /settings, preventing duplicate history entries from accumulating. A useRef tracks the current pathname inside the callback to avoid stale closure issues.

^{Macroscope summarized a954a23.}

Summary by CodeRabbit

• Bug Fixes
  • Improved sidebar navigation to prevent creating duplicate history entries when accessing the settings page from within the settings section, enhancing the back button behavior.

[coderabbitai]

📝 Walkthrough

Walkthrough

AppSidebarLayout component now tracks the current pathname using useLocation and stores it in a mutable ref to keep it available to event handlers. The /settings navigation from the desktop menu now conditionally uses history replace when the user is already within the /settings route, avoiding redundant history entries.

Changes

Settings navigation history management

Layer / File(s)	Summary
Pathname tracking and conditional navigation apps/web/src/components/AppSidebarLayout.tsx	Imports updated to include useLocation and useRef. Component tracks current pathname and syncs it to pathnameRef on render. /settings menu navigation uses replace: true when pathname already starts with /settings, otherwise performs a normal push.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~5 minutes

Poem

🐰 A sidebar so keen, now tracks where it's been,
Keeping history tidy, replace for settings, so nifty!
No redundant bounces, just smooth navigation pounces,
With refs and location hooks, this component now looks
Quite elegant indeed! 🌿✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title directly addresses the main change: preventing duplicate settings history entries when repeatedly opening settings via keyboard shortcut.
Description check	✅ Passed	The pull request description comprehensively covers all required template sections with clear explanations of changes, rationale, and interaction videos demonstrating the fix.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ 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 and usage tips.}

[macroscopeapp]

Approvability

Verdict: Approved

Simple UX fix that adds conditional replace: true to prevent browser history from stacking when navigating to settings while already in settings. Low risk, self-contained navigation behavior change.

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

Dismissing prior approval to re-evaluate 4ec0d32

[jamesx0416]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@apps/web/src/components/AppSidebarLayout.tsx`:
- Line 50: The replace decision uses pathnameRef.current.startsWith("/settings")
which incorrectly matches paths like "/settings-foo"; update the condition used
when calling navigate({ to: "/settings", replace: ... }) to perform a
boundary-safe check (e.g. test that pathnameRef.current is exactly "/settings"
or matches the "/settings" segment boundary such as using a regex like
/^\/settings(\/|$)/ or checking startsWith("/settings/")) so only true settings
routes trigger replace; locate the call in AppSidebarLayout where navigate and
pathnameRef.current are used and replace the startsWith check with the
boundary-safe check.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 77a90cc7-57b7-4e7a-9b9f-651716d83758

📥 Commits

Reviewing files that changed from the base of the PR and between d1e85c4 and 4ec0d32.

📒 Files selected for processing (1)

• apps/web/src/components/AppSidebarLayout.tsx

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Use a boundary-safe settings route check before replace.

Line 50 uses startsWith("/settings"), which also matches paths like /settings-foo. That can replace history unexpectedly outside the settings section.

Proposed fix

-        void navigate({ to: "/settings", replace: pathnameRef.current.startsWith("/settings") });
+        const isInSettings =
+          pathnameRef.current === "/settings" ||
+          pathnameRef.current.startsWith("/settings/");
+        void navigate({ to: "/settings", replace: isInSettings });

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	void navigate({ to: "/settings", replace: pathnameRef.current.startsWith("/settings") });
	const isInSettings =
	pathnameRef.current === "/settings" ||
	pathnameRef.current.startsWith("/settings/");
	void navigate({ to: "/settings", replace: isInSettings });

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/web/src/components/AppSidebarLayout.tsx` at line 50, The replace
decision uses pathnameRef.current.startsWith("/settings") which incorrectly
matches paths like "/settings-foo"; update the condition used when calling
navigate({ to: "/settings", replace: ... }) to perform a boundary-safe check
(e.g. test that pathnameRef.current is exactly "/settings" or matches the
"/settings" segment boundary such as using a regex like /^\/settings(\/|$)/ or
checking startsWith("/settings/")) so only true settings routes trigger replace;
locate the call in AppSidebarLayout where navigate and pathnameRef.current are
used and replace the startsWith check with the boundary-safe check.