You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(web): add a setting to disable history swipe navigation - #28370
On macOS desktop, a Logitech MX Master's horizontal thumb wheel can navigate thread history accidentally, including when horizontal scrolling reaches the edge of wide content. Electron 44's input events carry no trackpad-vs-wheel provenance, so the existing gesture cannot currently be restricted to trackpads.
Change
Add “Swipe to go back and forward” in desktop Settings > General > Navigation, with Settings search, a per-setting reset, and restore-defaults support. The client preference defaults to enabled. Turning it off unmounts the gesture handler and indicator immediately, including during a swipe; turning it on works without reloading. Mouse back/forward buttons and keyboard navigation retain their existing behavior.
Scope and approval
CONTRIBUTING.md states: “A focused configuration option for an established capability may also be eligible without prior feature approval.” This option controls the existing desktop history-swipe capability. The default is unchanged, and the scope adds no workflow or broader navigation behavior. This follows the configuration route; it does not claim explicit maintainer approval or guaranteed acceptance.
The change is limited to the client setting contract, desktop renderer Settings/search/reset integration, its mount gate, and focused tests. Hosted/local web and native mobile do not expose the desktop gesture. The gesture is not documented in user guides, so no documentation change is needed.
Verification
Failing first on origin/main at 15fe283, with only regression tests added: both disabled swipe directions still invoked history navigation once; three schema cases failed because the field was absent (5 failures, 28 existing tests passed).
With the change: 59 tests passed across settings contracts, AppSidebarLayout browser behavior, the existing swipe helper, and Settings search. Covers disabled back/forward navigation, removal of the indicator during an active swipe, and re-enabling without a reload.
Command: vp test run packages/contracts/src/settings.test.ts apps/web/src/components/AppSidebarLayout.browser.test.tsx apps/web/src/components/HistorySwipeNavigation.test.ts apps/web/src/components/settings/settingsSearch.test.ts.
vp run check:changed: passed (exit 0): format, lint, both knip passes, typecheck of 35 affected packages/dependents, 64 tests across six files, and four changed-source React Compiler cases.
Manual check in a desktop build carrying this change (recording below).
Evidence
Settings > General > Navigation, enabled and disabled:
Recording: 0–10 s the setting is on and horizontal swipes move between threads; at 12 s it is turned off; 15–24 s the same swipes leave the thread in place.
swipe-demo.mp4
Model: gpt-6.1-sol via Codex CLI, orchestrated by Claude Code.
Horizontal mouse wheels can accidentally navigate desktop thread history.
Electron input events do not distinguish a trackpad swipe from a mouse wheel.
Add a default-enabled client setting with desktop Settings search and reset
support. Unmount the gesture handler when disabled, and cover disabling,
mid-swipe cleanup, and re-enabling with focused regression tests.
Model: gpt-6.1-sol via Codex CLI, orchestrated by Claude Code.
Macroscope's review found this PR approvable — Adds a desktop setting to disable swipe history navigation while keeping it enabled by default. The change is reversible and removes gesture listeners when disabled.
You can add or adjust custom eligibility rules. Learn more.
No actionable comments were generated in the recent review.
Walkthrough
The change adds a client setting for desktop history swipe navigation. It defaults to enabled, appears in Electron General settings, and controls whether AppSidebarLayout renders the navigation component.
ClientSettingsSchema defaults historySwipeNavigation to true. ClientSettingsPatch accepts an optional boolean. Tests cover omitted and explicit values.
Settings controls and search apps/web/src/components/settings/SettingsPanels.tsx, apps/web/src/components/settings/settingsSearch.ts, apps/web/src/components/settings/settingsSearch.test.ts
The Electron General settings panel exposes the setting and a reset action. Restore tracking and restoring defaults include it. Desktop settings search indexes the setting.
AppSidebarLayout renders HistorySwipeNavigation only in Electron when the setting is enabled. Browser tests cover disabled and enabled behavior in both directions. The indicator has a test ID.
pingdotgg/t3code issue 32955 — The issue reports horizontal mouse-wheel input triggering desktop thread-history swipes and identifies an opt-out setting as a possible fix. This change adds that setting and gates the swipe component on its value.
Possibly related PRs
pingdotgg/t3code#27430 — Adds the desktop history-swipe gesture that this change gates with a setting.
pingdotgg/t3code#31728 — Adds the same setting and related settings, restore, search, and contract support.
pingdotgg/t3code#29766 — Changes when HistorySwipeNavigation invokes history navigation; this change gates that handler and tests disabled behavior.
Suggested reviewers:juliusmarminge
Merge Risk: Minimal · up to 18909
The swipe setting appears ready to merge after normal checks; no actionable issue is identified.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title clearly summarizes the main change: adding a setting to disable history swipe navigation.
Description check
The description includes the required Problem, Change, Scope and approval, and Verification sections. It explains the issue and behavior, defines the scope and approval rationale, reports focused test…
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.
Full details: Description check
Explanation
The description includes the required Problem, Change, Scope and approval, and Verification sections. It explains the issue and behavior, defines the scope and approval rationale, reports focused test results, and provides screenshots and a recording for the UI change.
Finishing Touches
Generate unit tests (beta)
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.
merged current main into the branch at 18909a592b (merge commit, no rebase). one conflict in AppSidebarLayout.tsx: main added a showSidebar prop, the pr gates HistorySwipeNavigation on the setting. both kept. no other source changes; no required changes or actionable bot findings.
blacksmith: vp run check:changed passed (format, lint, knip, typecheck of 37 packages, 7 test files, react compiler). AppSidebarLayout.browser.test.tsx, settingsSearch.test.ts and contracts settings.test.ts pass.
the electron client was not re-driven after the merge. the evidence below is from db2a71b.
Earlier verification (gpt-6.1-sol)
Verified in a real dev environment
verified as-is at db2a71b12f7d5a389f60aa0fc05f1ff56c72de54 on this linux vm. no source changes.
reproduced on github/main at 8b74a69019e3 first: horizontal wheel input navigates between threads, with no setting to disable it.
used real dev servers, chrome through repository playwright, and the actual electron 44 desktop client built from each revision. created a real git project and two threads through the app. codex gpt-6.1-sol completed both main turns and another turn through the pr's web client. no mocks or seeded conversations.
in desktop settings, the control defaults on. switching off blocks both directions and removes the indicator. re-enabling restores both directions without reload. disabling during a swipe removes its indicator. the disabled preference survives reload.
keyboard and toolbar back/forward still work while swipes are disabled. settings search for "horizontal wheel", per-setting reset, and restore device defaults work. chrome correctly hides the desktop-only control.
blacksmith: desktop build and vp run check:changed 15fe2832727893cbdd2214383f9f971474849695 passed, including 35-package typechecking, 64 tests across six files, and four react compiler cases. all 31 reported ci checks pass.
after disabling, the real-client checks reported:
disabled back swipe keeps beta true
disabled swipe has no indicator true
keyboard back still works while disabled true
disabled forward swipe keeps alpha true
keyboard forward still works while disabled true
toolbar back still works while disabled true
toolbar forward still works while disabled true
re-enabled back swipe works without reload true
re-enabled forward swipe works without reload true
before, main settings with matching project data and viewport:
pr, enabled:
pr, disabled:
main: horizontal wheel input moves beta to alpha and back.
pr: disabled swipes leave the thread unchanged; keyboard and toolbar navigation still work; enabling restores swipe navigation. these animations contain the full recordings. the original mp4s were inspected and played through in t3, including seeking.
Not verified
macos hardware input from a physical trackpad or logitech mx master, mouse thumb buttons, windows desktop, native ios/android, and relay/tunnel connections were not exercised on this linux vm. the wheel checks used trusted chromium input through the real electron renderer and gesture ipc, so they do not prove macos hardware event provenance.
I'm a huge +1 on this PR. I use an Apple Magic Trackpad, and I couldn't understand what was happening: while I was scrolling, my threads kept suddenly switching from one to another.
I keep running into issues using shift+scroll to horizontally scroll diffs but end up over scrolling and moving forward/back in navigation history. It's incredibly obnoxious. Would this proposed setting fix that since over scrolls are considered swipes?
+1. Same on macOS desktop with an MX Master 3S: horizontally scrolling a wide Markdown table with the thumb wheel, once the table hits its edge the swipe indicator appears and the app jumps to another thread. It is easy to miss and confusing. It also happens with the trackpad in the same situation, so a setting to turn the gesture off would help both cases.
Same issue on Zorin OS 18.1 (Ubuntu-based), Wayland, T3 Code 0.1.7, with an MX Master 4. Horizontal thumb-wheel scrolling switches threads. Would appreciate this toggle.
This switch is the per-user escape hatch the platform check cannot provide: mouse users on macOS can turn the gesture off without taking it away from trackpad users. If #32963 lands first, I'll rebase and show the switch only where the gesture exists. #31728 proposes the same switch; happy to close this one in favour of whichever you prefer.
macos hardware input from a physical trackpad or logitech mx master, mouse thumb buttons, windows desktop, native ios/android, and relay/tunnel connections were not exercised on this linux vm.
Adding the hardware side that the verification above could not cover (it ran on a Linux VM with synthetic wheel input).
I have used this change daily since 31 October in desktop builds on a MacBook Pro on macOS 26.6 with a Logitech MX Master and the built-in trackpad:
Switch on (the default): a two-finger trackpad swipe goes back and forward as on main. The MX Master's thumb wheel triggers the same navigation, which is the misfire that made me open this PR.
Switch off: neither the thumb wheel nor a trackpad swipe changes the thread. Keyboard and toolbar back/forward still work.
The choice has survived every restart and app update since.
On #32963: it leaves macOS unchanged, so this case stays open there. If it lands first, I'll rebase this PR and show the switch only where the gesture exists.
The reason will be displayed to describe this comment to others. Learn more.
Really agree with adding this as a toggleable feature. I think the suggested changes here just make the wording a little simpler and fit in with the rest of the settings a little better. Would love to see this merged!
@maria-rcks@juliusmarminge thanks for keeping this one and closing my duplicate (#34481). +1 to merge: it is clean against main, and kelchm and chomamateusz have confirmed it on macOS with a trackpad and an MX Master.
Two small refinements from #34481 that Julius mentioned. Neither needs to block this PR; I can open them as a follow-up after it merges, or you can take them here:
One line in docs/user/keybindings.md, after navigation.back / navigation.forward: "In the desktop app on macOS, a two-finger trackpad swipe does the same. Turn it off in Settings."
This branch has not been deployed
No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size:M30-99 changed lines (additions + deletions).vouch:unvouchedPR author is not yet trusted in the VOUCHED list.
11 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
vouch:unvouched
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
alex-delia
left a comment
Problem
On macOS desktop, a Logitech MX Master's horizontal thumb wheel can navigate thread history accidentally, including when horizontal scrolling reaches the edge of wide content. Electron 44's input events carry no trackpad-vs-wheel provenance, so the existing gesture cannot currently be restricted to trackpads.
Change
Add “Swipe to go back and forward” in desktop Settings > General > Navigation, with Settings search, a per-setting reset, and restore-defaults support. The client preference defaults to enabled. Turning it off unmounts the gesture handler and indicator immediately, including during a swipe; turning it on works without reloading. Mouse back/forward buttons and keyboard navigation retain their existing behavior.
Scope and approval
CONTRIBUTING.md states: “A focused configuration option for an established capability may also be eligible without prior feature approval.” This option controls the existing desktop history-swipe capability. The default is unchanged, and the scope adds no workflow or broader navigation behavior. This follows the configuration route; it does not claim explicit maintainer approval or guaranteed acceptance.
The change is limited to the client setting contract, desktop renderer Settings/search/reset integration, its mount gate, and focused tests. Hosted/local web and native mobile do not expose the desktop gesture. The gesture is not documented in user guides, so no documentation change is needed.
Verification
vp test run packages/contracts/src/settings.test.ts apps/web/src/components/AppSidebarLayout.browser.test.tsx apps/web/src/components/HistorySwipeNavigation.test.ts apps/web/src/components/settings/settingsSearch.test.ts.vp run check:changed: passed (exit 0): format, lint, both knip passes, typecheck of 35 affected packages/dependents, 64 tests across six files, and four changed-source React Compiler cases.Evidence
Settings > General > Navigation, enabled and disabled:
Recording: 0–10 s the setting is on and horizontal swipes move between threads; at 12 s it is turned off; 15–24 s the same swipes leave the thread in place.
swipe-demo.mp4
Model: gpt-6.1-sol via Codex CLI, orchestrated by Claude Code.