[Feature Request] Add cli command to open folder inside desktop app

[maxceem]

It's super useful to open a folder as a project in desktop apps from terminal.

For example I'm inside terminal and I want to open current folder in t3code, it's great to have a cli command installed together with desktop app which would work like this:

$ t3code <folder path>

or

$ t3code

which should add mentioned folder <folder path> or current folder to the desktop app and make it current.

Some desktop apps support this feature, example:

• $ code . - VS Code
• $ fork - Desktop Git UI App

[azimari-toure-ikbal]

I'd love this. I spend a lot of time navigating through my projects in the terminal and opening them with aliases for vscode and cursor. This would be a great addition !

[anduimagui]

I would love this too. I am adding T3 Code support to a Raycast command that opens local coding projects.

At the moment, Raycast can start T3 Code, but it cannot tell the desktop app which folder to open. A command such as:

t3code /path/to/project

would be ideal. A deep link such as t3code://open-project?path=... would also work.

The main requirement is that it works when the app is both closed and already running. It should open or focus the desktop app, add the project if needed, and select it.

It looks like most of the related work was explored in #2244 and #2544. Current main also registers the t3code:// scheme, but the second-instance handler does not use the supplied URL or arguments yet.

Related: #4996 covers thread deep links, and #5978 covers URLs lost by the second-instance handler.

[sieversjosua]

The CLI side of this is being tackled in #7176 (t3 <path> attaches to a running desktop/server). There is a complementary gap that a CLI can't cover: GUI launchers without a shell. Raycast's app-open action, open -a "T3 Code" <dir> from any tool, and dragging a folder onto the Dock icon (#6700) all reach the desktop app as macOS open-file events today — and the app silently drops them: no open-file handler in the main process, no folder document type in the Info.plist.

I have this implemented and verified locally:

• a strict pre-ready buffer so launch-time open-file events survive cold start (they fire before the main process finishes bootstrapping)
• a small desktop service that validates paths (directories only), dedupes, and queues them; the renderer drains the queue once the authenticated shell is up and routes through the same add-project flow as the command palette — an already-added folder jumps to its latest thread instead of duplicating
• CFBundleDocumentTypes (public.folder, rank Alternate) so Finder accepts Dock drops without T3 Code entering the default-folder-handler race
• works whether the app is closed, starting, or already running; requests queued while signed out drain right after sign-in

Verified against a dev build (open -a "T3 Code (Dev)" <dir> → project added + thread opened; same dir again → navigates, no duplicate; file paths ignored), plus unit tests, with the full desktop suite green. Scoped to macOS — Windows/Linux second-instance argv is left alone since #7180 is reworking that handler for deep links.

Following CONTRIBUTING's "discuss changes first": if the maintainers want this, I'll open the PR.