[Ipriyankrajai]

Summary

• Decouples the existing-pane lookup from the openInNewTab flag in addFileViewerPane
• Previously, when file-open mode was set to "new-tab", the store skipped searching for an already-open pane entirely, which could create duplicates
• Now the store always finds an existing pane first, but only reuses it in-place when openInNewTab is false

Screen.Recording.2026-04-02.at.2.07.41.AM.mov

Test plan

• Set file-open mode to "New tab" in Settings → Behavior
• Open a file — verify it opens in a new tab
• Open the same file again — verify it activates the existing tab instead of creating a duplicate
• Set file-open mode to "Split pane" and verify normal split-pane reuse still works
• Cmd+click a file (force new tab) — verify it still opens in a new tab

---

Summary by cubic

Prevent duplicate file-viewer panes when file-open mode is set to "New tab". The store now always finds an existing pane first and only reuses it when openInNewTab is false, so opening the same file activates the existing tab; split-pane reuse and cmd+click to force a new tab still work as before.

^{Written for commit dd12096. Summary will update on new commits.}

Summary by CodeRabbit

• Refactor
  • Streamlined internal logic for managing file viewer pane reuse behavior.

[coderabbitai]

📝 Walkthrough

Walkthrough

The addFileViewerPane function in the tabs store was refactored to simplify reuse logic for file-viewer panes. An intermediate canReuseExistingPane boolean variable was removed, with its reuse condition now directly inlined in both relevant code paths where the pane reuse decision is made.

Changes

Cohort / File(s)	Summary
Tabs Store Refactoring apps/desktop/src/renderer/stores/tabs/store.ts	Removed intermediate canReuseExistingPane boolean; inlined reuse condition (!options.openInNewTab && reuseExisting !== "none") directly in both code paths for consistency and clarity.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

A variable hopped away with a bound,
Its logic now flows without making a sound—
Two paths sing the same simple refrain,
Simplicity blooms like clover again! 🐰✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main fix: preventing duplicate panes when file-open mode is set to new-tab, which matches the core change in the PR.
Description check	✅ Passed	The description includes a clear summary, detailed explanation of the problem and solution, comprehensive test plan with verification steps, and supporting video evidence. However, required template sections like 'Type of Change', 'Related Issues', and 'Testing' checkboxes are not fully completed in the standard format.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ 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.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/desktop/src/renderer/stores/tabs/store.ts (1)

722-769: ⚠️ Potential issue | 🟠 Major

Explicit force-new-tab can be bypassed by workspace-wide file search.

When a file is already open in the workspace, the lookup at lines 759-769 searches across all workspace tabs and returns the existing pane without checking whether openInNewTab was explicitly set to true (e.g., Cmd+click). This prevents creating a new tab as requested.

The guard at line 829 (!options.openInNewTab) only protects the active-tab-only search path and is unreachable if the workspace search succeeds first.

Add && !isExplicitOpenInNewTab to the lookup gate at line 759 to respect explicit force-new-tab intent:

Proposed fix

 addFileViewerPane: (
   workspaceId: string,
   options: AddFileViewerPaneOptions,
 ) => {
+  const isExplicitOpenInNewTab = options.openInNewTab === true;
   if (options.openInNewTab === undefined) {
     options = {
       ...options,
       openInNewTab: getFileOpenMode() === "new-tab",
     };
   }
   
   const state = get();
   const resolvedActiveTabId = resolveActiveTabIdForWorkspace({
     workspaceId,
     tabs: state.tabs,
     activeTabIds: state.activeTabIds,
     tabHistoryStacks: state.tabHistoryStacks,
   });
   const activeTab = resolvedActiveTabId
     ? state.tabs.find((t) => t.id === resolvedActiveTabId)
     : null;
   
   if (!activeTab) {
     const { tabId, paneId } = get().addTab(workspaceId);
     const fileViewerPane = createFileViewerPane(tabId, options);
     set((s) => ({
       panes: {
         ...s.panes,
         [paneId]: {
           ...fileViewerPane,
           id: paneId,
         },
       },
     }));
     return paneId;
   }
   
   const tabPaneIds = extractPaneIdsFromLayout(activeTab.layout);
   const reuseExisting = options.reuseExisting ?? "workspace";
   const existingFileViewerPane = reuseExisting !== "none" && !isExplicitOpenInNewTab
     ? findReusableFileViewerPane({
         workspaceId,
         activeTabId: activeTab.id,
         tabs: state.tabs,
         panes: state.panes,
         tabHistoryStacks: state.tabHistoryStacks,
         reuseExisting,
         options,
       })
     : null;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/desktop/src/renderer/stores/tabs/store.ts` around lines 722 - 769, The
workspace-wide reuse check can bypass an explicit "open in new tab" request;
update the existingFileViewerPane assignment condition so the workspace search
is skipped when the user explicitly forced a new tab (i.e., add a guard like &&
!isExplicitOpenInNewTab or && !options.openInNewTab). Specifically, modify the
ternary that sets existingFileViewerPane (the call to
findReusableFileViewerPane) to only run when reuseExisting !== "none" AND the
explicit-new-tab flag is false, so createFileViewerPane/addTab is used when the
user requested a new tab.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@apps/desktop/src/renderer/stores/tabs/store.ts`:
- Around line 722-769: The workspace-wide reuse check can bypass an explicit
"open in new tab" request; update the existingFileViewerPane assignment
condition so the workspace search is skipped when the user explicitly forced a
new tab (i.e., add a guard like && !isExplicitOpenInNewTab or &&
!options.openInNewTab). Specifically, modify the ternary that sets
existingFileViewerPane (the call to findReusableFileViewerPane) to only run when
reuseExisting !== "none" AND the explicit-new-tab flag is false, so
createFileViewerPane/addTab is used when the user requested a new tab.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 4f068e53-78d3-4839-a96c-a194d9f20abf

📥 Commits

Reviewing files that changed from the base of the PR and between a2e9531 and dd12096.

📒 Files selected for processing (1)

• apps/desktop/src/renderer/stores/tabs/store.ts

[cubic-dev-ai]

No issues found across 1 file