What I'd like
A way for another application to ask LM Studio to open a folder as a project. Any one of these would do:
- A deeplink route —
lmstudio://open_project?path=<absolute-path>
- An
lms CLI verb — lms project open <path>
- The existing project RPC exposed on the SDK websocket
Only one is needed. A deeplink is probably the smallest.
Why
I maintain an editor that sets up local agents to work against a user's folder — it writes the MCP server entry and drops Agent Skills where each tool reads them. For LM Studio that works nicely: ~/.lmstudio/mcp.json for MCP, ~/.lmstudio/skills for user-global skills, and <workingDir>/.agents/skills for project skills, which is a great choice.
The one thing I can't do is the last step — hand LM Studio the folder. Every other agent I support takes either a URL scheme or a CLI argument, so "open this project in X" is one click. For LM Studio the user has to open the app, create or pick a project, and set its working directory by hand before any of the setup applies.
Why I think this is small
Looking at the app, opening a folder as a project is something LM Studio already does — there's setProjectWorkingDirectoryPath (which takes a path), openProject, openProjectLauncher, and a create-project flow that sets the working directory from a path at creation. As far as I can tell these live on the internal main↔renderer channel, so nothing outside the app can reach them. The ask is really just to expose one of the existing entry points, not to build new behaviour.
What I checked first
- The
lmstudio:// scheme handles search, downloadPreset, downloadPlugin, downloadModel and addMCP. None of them takes a path, folder or prompt.
- No
CFBundleDocumentTypes are declared, so open -a "LM Studio" <folder> has nothing to bind to.
lms has no project/workspace verbs — models, server, runtime and hub publishing only.- No
open-file handler or command-line path handling that I could find.
I did also find that project state is plain files under ~/.lmstudio, so I could technically write a project entry pointing at a path. I don't want to do that — it's undocumented internal state next to a live database, and it would break quietly on your next release and look like a bug in my app rather than a bad idea in it. Hence asking properly.
Version
Verified against 0.4.21+2 on macOS (Apple Silicon). I see 0.4.23 is out — if any of this has already changed there, apologies, and please just point me at it.
Happy to test a build if that's useful.
What I'd like
A way for another application to ask LM Studio to open a folder as a project. Any one of these would do:
lmstudio://open_project?path=<absolute-path>lmsCLI verb —lms project open <path>Only one is needed. A deeplink is probably the smallest.
Why
I maintain an editor that sets up local agents to work against a user's folder — it writes the MCP server entry and drops Agent Skills where each tool reads them. For LM Studio that works nicely:
~/.lmstudio/mcp.jsonfor MCP,~/.lmstudio/skillsfor user-global skills, and<workingDir>/.agents/skillsfor project skills, which is a great choice.The one thing I can't do is the last step — hand LM Studio the folder. Every other agent I support takes either a URL scheme or a CLI argument, so "open this project in X" is one click. For LM Studio the user has to open the app, create or pick a project, and set its working directory by hand before any of the setup applies.
Why I think this is small
Looking at the app, opening a folder as a project is something LM Studio already does — there's
setProjectWorkingDirectoryPath(which takes a path),openProject,openProjectLauncher, and a create-project flow that sets the working directory from a path at creation. As far as I can tell these live on the internal main↔renderer channel, so nothing outside the app can reach them. The ask is really just to expose one of the existing entry points, not to build new behaviour.What I checked first
lmstudio://scheme handlessearch,downloadPreset,downloadPlugin,downloadModelandaddMCP. None of them takes a path, folder or prompt.CFBundleDocumentTypesare declared, soopen -a "LM Studio" <folder>has nothing to bind to.lmshas no project/workspace verbs — models, server, runtime and hub publishing only.open-filehandler or command-line path handling that I could find.I did also find that project state is plain files under
~/.lmstudio, so I could technically write a project entry pointing at a path. I don't want to do that — it's undocumented internal state next to a live database, and it would break quietly on your next release and look like a bug in my app rather than a bad idea in it. Hence asking properly.Version
Verified against 0.4.21+2 on macOS (Apple Silicon). I see 0.4.23 is out — if any of this has already changed there, apologies, and please just point me at it.
Happy to test a build if that's useful.