[argval]

Summary

• t3 . / t3 <path> now opens that directory as a project instead of always starting a new server.
• If a T3 backend is already running for this home (desktop or CLI), it adds or reuses the project there.
• If nothing is running, it tries to launch the installed desktop app, waits for its backend, then attaches; otherwise it falls back to starting the CLI server as before.

Why

Users expect cursor . / code . ergonomics: from a repo, open it in the app. Bare t3 still starts a server; only a positional path triggers open.

Out of scope

• Deep-linking the UI into a specific thread (project appears in the sidebar).
• Electron argv / second-instance path parsing (CLI talks to the live backend instead).

Test plan

• With desktop running: t3 /path/to/repo adds/reuses the project in ~/.t3 and shows it in the sidebar
• Run the same path twice → same project id (no duplicate)
• With only npx t3 / vp run dev server up: path attaches to that server’s home
• With nothing running and desktop installed: t3 . launches desktop and opens the folder
• With nothing running and no desktop: t3 . starts the CLI server (previous behavior)
• vp test run apps/server/src/bin.test.ts apps/server/src/cli/desktopLaunch.test.ts

Made with Cursor

Note

Open a folder in desktop app or running server via t3 .

• When a directory argument is passed to the t3 CLI, it first tries to attach to an already-running server via openLiveProjectIfPresent, then falls back to launching the desktop app (polling for readiness), and only starts a new CLI server if both fail.
• Adds tryLaunchDesktopApp in desktopLaunch.ts with cross-platform support: open -a on macOS, spawning executables under LocalAppData on Windows, and gtk-launch with .desktop file discovery on Linux.
• Adds findAliveServerRuntimeCandidates in pair.ts to enumerate live server processes across userdata and dev state variants before HTTP probing.
• Behavioral Change: t3 . no longer always starts a server; it may return early after opening the project in an existing process.

^{Macroscope summarized a6ee964.}

[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: f5181df3-ccf0-4639-8e98-98db4770bf98

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

---

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]

Effect service conventions review of the changed TypeScript. One finding: the new desktopLaunch.ts resolves the host platform from the Effect environment but reads the host environment from the process global.

^{Posted via Macroscope — Effect Service Conventions}

[argval]

Addressed both Macroscope notes:

1. Desktop poll timeout now returns false so we fall back to runServerCommand.
2. Windows launch waits for the child's spawn/error before succeeding, and continues to the next candidate on failure.

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces a new feature that changes CLI behavior: t3 . now attempts to attach to running servers or launch the desktop app before starting a CLI server. Adds ~300 lines of cross-platform desktop launch logic and orchestration integration, warranting human review.

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

[argval]

Also fixed the remaining Bugbot note: the first openLiveProjectIfPresent probe now uses clearOnFailure: false, so a transient miss cannot delete a live desktop/server server-runtime.json before launch/poll.

[macroscopeapp]

One finding in apps/server/src/cli/desktopLaunch.ts: the desktop launch effect acquires its process/filesystem capabilities from Node globals rather than the Effect environment. (The previously reported process.env.LOCALAPPDATA / NodeOS.homedir() default on line 17 is still present and is part of the same issue.)

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One new finding in apps/server/src/cli/project.ts. The two previously reported issues in apps/server/src/cli/desktopLaunch.ts (runtime-backed spawnSync/spawn/existsSync and process.env.LOCALAPPDATA not acquired from the Effect environment alongside HostProcessPlatform) are unchanged at this head; see the existing inline comments rather than new duplicates.

^{Posted via Macroscope — Effect Service Conventions}

[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 e9a31ce. Configure here.}

[macroscopeapp]

One convention finding on the new live-open path in apps/server/src/cli/project.ts: statically known tagged failures are classified with Schema.is predicates instead of Effect.catchTags. Everything else in the diff (environment-acquired ChildProcessSpawner / HostProcessEnvironment / FileSystem in desktopLaunch.ts, namespace subpath imports, no service-instance injection or hidden runtimes) matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

This adds a new CLI-to-desktop or server routing workflow for t3 .. We do not want to add the discovery, selection, and launch behavior through this branch.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.