fix(open-file): strip Next.js App Router virtual path segments before editor launch

[Logesh-waran2003]

What

Fixes Open in editor silently failing for all Next.js App Router users.

Why

Next.js App Router's dev server injects a virtual path segment /(app-pages-browser)/ into stack frame file paths. For example, a real file at:

/Users/me/project/app/components/Button.tsx

appears in the stack as:

/Users/me/project/app/(app-pages-browser)/components/Button.tsx

tryDevServerOpen() was passing this corrupted path directly to /__nextjs_launch-editor. The editor receives a path that doesn't exist on disk, so the file never opens — no error, just silence.

Fix

Strip the /(app-pages-browser)/ segment before building the URLSearchParams, scoped to Next.js projects only:

const stripAppRouterVirtualSegments = (filePath: string): string =>
  filePath.replace(/\/\(app-pages-browser\)\//g, "/");

One function, one call site. No changes to the Vite path.

Fixes #215

🤖 Generated with Claude Code

---

Note

Low Risk
Small, scoped string normalization change applied only for detected Next.js projects; minimal impact outside the editor-launch path.

Overview
Fixes “Open in editor” failures in Next.js App Router projects by stripping the injected /(app-pages-browser)/ virtual path segment from stack-frame file paths.

The normalized path is now used consistently for the dev-server launch endpoint (/__nextjs_launch-editor) and for the fallback buildOpenFileUrl/transformUrl flow, while non-Next (Vite) behavior remains unchanged.

^{Written by Cursor Bugbot for commit 4455b41. This will update automatically on new commits. Configure here.}

---

Summary by cubic

Restore “Open in editor” for Next.js App Router by stripping the injected /(app-pages-browser)/ segment from stack-frame file paths before launching the editor. Normalization now applies to both the Next.js launch-editor request and the fallback open-file URL; only affects Next.js projects, Vite remains unchanged.

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

[pullfrog]

This run croaked 😵

The workflow encountered an error before any progress could be reported. Please check the link below for details.

  ^{｜ Rerun failed job ➔ ｜ View workflow run ｜ Triggered by Pullfrog ｜ pullfrog.com ｜ 𝕏}

[vercel]

@Logesh-waran2003 is attempting to deploy a commit to the Million Team on Vercel.

A member of the Team first needs to authorize it.

[cubic-dev-ai]

No issues found across 1 file

---

Since this is your first cubic review, here's how it works:

• cubic automatically reviews your code and comments on bugs and improvements
• Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
• Add one-off context when rerunning by tagging @cubic-dev-ai with guidance or docs links (including llms.txt)
• Ask questions if you need clarification on any suggestion

[vercel]

Additional Suggestion:

When the dev server method fails, the fallback web-based open-file method receives an unstripped filePath containing Next.js virtual segments /(app-pages-browser)/, causing the fallback to fail as well

[Logesh-waran2003]

Good point — fixed. Normalized the path before the dev server call and reused the normalized path in the fallback buildOpenFileUrl call too, so both paths get the clean path.

[cursor]

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

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

[cursor]

Path stripped twice due to redundant normalization

Low Severity

stripAppRouterVirtualSegments is applied twice for Next.js projects — once in openFile before passing normalizedPath to tryDevServerOpen, and again inside tryDevServerOpen on the already-stripped path. Since tryDevServerOpen is private and only called from openFile, one of these two call sites is redundant. The cleanest fix is to remove the conditional strip inside tryDevServerOpen (line 15), since the caller already normalizes the path.

Additional Locations (1)

• packages/react-grab/src/utils/open-file.ts#L34-L40