Add support for custom app_id for window managers

[mkungla]

This PR adds an app_id field to App, allowing users to set a custom app ID via the new --app-id command-line argument. build_window_options now uses cx.app_id, defaulting to the release channel app ID if none is provided.

Why?

While there are other potential use cases for a custom app_id, I personally use this to make it easier to manage multiple org/project workspaces. Zed’s concepts of Workspaces and Projects can be a bit confusing, and support for multi-root workspaces is currently missing (see issues #9459, #15120, and likely others). There's also no way to open a workspace by ID from workspaces table in db.sqlite.

Instead of making big or breaking changes, this PR introduces a minimal but useful tweak to help mitigate the lack of more advanced workspace support.

For example, having follwing project structure :

org1
    ├── logo.png
    ├── project-1
    ├── project-2
    └── project-3

Then, using a custom .desktop entry, you can assign a unique app_id so that window managers group all projects from the same org together. This doesn’t fully solve the problem of managing complex/multi-root workspaces, but it does provide a small quality-of-life improvement when dealing with massive org codebases.

Example dev.zed.Zed-Org1.desktop entry

[Desktop Entry]
Version=1.0
Type=Application
Name=Org 1
GenericName=Text Editor
TryExec=zed
Exec=zed-editor --app-id dev.zed.Zed-Org1 /devel/org1
Icon=/devel/org1/logo.png
Categories=Workspaces;
Actions=Project1;Project2;Project3;

[Desktop Action Project1]
Exec=zed-editor --app-id dev.zed.Zed-Org1 /devel/org1/project-1
Name=Open a project 1

[Desktop Action Project2]
Exec=zed-editor --app-id dev.zed.Zed-Org1 /devel/org1/project-2
Name=Open a project 2

[Desktop Action Project3]
Exec=zed-editor --app-id dev.zed.Zed-Org1 /devel/org1/project-3
Name=Open a project 3

Release Notes:

• Add support for custom app_id for window managers and --app-id flag

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @mkungla on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[mkungla]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[zed-industries-bot]

	Warnings
⚠️	This PR is missing release notes. Please add a "Release Notes" section that describes the change: Release Notes: - Added/Fixed/Improved ... If your change is not user-facing, you can use "N/A" for the entry: Release Notes: - N/A

Generated by 🚫 dangerJS against b2dbe2b

[mikayla-maki]

Thank you for the contribution, we actually do support multi-root workspaces via the workspace::AddFolderToProject action. If this isn't sufficient for your use case, we'd be open to reconsidering if you can find other examples of people using this app ID trick to accomplish similar goals :)

[mkungla]

Hi @mikayla-maki, thanks for reviewing my PR! I totally get that Zed supports multi-root workspaces via workspace::AddFolderToProject, but I think my proposal tackles a different angle that might’ve been unclear in my initial description - sorry about that! I’d love to clarify and see if this fits Zed’s vision.

The --app-id flag isn’t about enabling multi-root setups (which you’ve already handled well) but about scoping Zed’s entire state - like the SQLite database and settings - to a specific context. For example, zed-editor --app-id MyOrg creates a MyOrg_zed.db, isolating all projects and folders (added via AddFolderToProject) from other Zed instances (e.g., personal projects or another org). This keeps search, commands, and even live collaboration scoped to that context without overlap.

This ties into issues like #9459 and #15120, where users want more control over workspace boundaries - #9459 (89 upvotes) calls for .code-workspace files, and #15120 highlights monorepo struggles with shared state. My PR doesn’t solve those fully, but it’s a step toward that flexibility. Plus, with Zed’s live shared editing, it’s a game-changer for security: if I’m working with Org1 and Org2 under separate NDAs, --app-id Org1 and --app-id Org2 ensure no accidental data leaks across orgs during collaboration. Without this, the shared database risks mixing everything up.

A few questions to dig deeper:

• Does this isolation use case - especially for collaboration - align with user needs you’re seeing?
• Is there a bigger multi-root or workspace plan that this might overlap with?
• If the approach isn’t ideal, any tips on tweaking it to fit Zed’s design better?

I’m really impressed by Zed’s potential - it’s incredible work - and I’d love to refine this if it’s valuable. Happy to adjust the PR or brainstorm alternatives based on your feedback. Thanks again! :)

[mikayla-maki]

I see the kind of feature you're imagining building too, but I don't think that changing the app ID is a good way to do it for 2 reasons:

• App ID is a Linux-specific concept. This kind of scoped / isolated Zed installation needs a cross-platform solution, perhaps something like Portable Mode
• This specific use case seems like a misuse of the App ID, based on a cursory reading of the GNOME docs

[mkungla]

Hey @mikayla-maki, thanks for the feedback—glad the idea’s clicking! I see the App ID concern, but I think it’s more portable than it looks. It’s not really GNOME-specific --app-id just suffixes the data dir and DB (e.g., zed-myorg.db), which works on macOS/Windows too, not just Linux. Users can rig it however - like .desktop files or aliases. Portable Mode’s awesome (love VS Code’s take), but it’s a bigger lift, while this is a quick, cross-platform win now. Maybe --instance-id fits better than --app-id to avoid confusion? Thoughts on keeping this light and usable today?

[mikayla-maki]

@mkungla That's not how Zed's database is selected. You can see here:

zed/crates/db/src/db.rs

Line 143 in 4453fc4

let db_dir = $crate::database_dir();

That we generate the database name via release channel, and then use XDG_DATA_HOME to get the directory for it:

First via database_dir():

zed/crates/paths/src/paths.rs

Line 125 in 4453fc4

DATABASE_DIR.get_or_init(|| support_dir().join("db"))

Which in turn calls support_dir():

zed/crates/paths/src/paths.rs

Line 48 in 4453fc4

dirs::data_local_dir().expect("failed to determine XDG_DATA_HOME directory")

Perhaps you could use something like direnv to change XDG_DATA_HOME in each project, to get the same results?

[mkungla]

@mikayla-maki, thanks for breaking down the DB logic - really clarifies things! I see how Zed ties the DB name to the release channel (e.g., zed-<channel>.db) and uses XDG_DATA_HOME for the dir. My --app-id just appends to that path, and it’s cross-platform - e.g., ~/Library/Application Support/zed-myorg on macOS too. direnv could work, but it’s extra setup for users when a flag could do it cleaner. What if we used --data-dir to set a custom base dir, keeping the channel naming? Like zed-<channel>.db in ~/.local/share/zed-myorg/db. Keeps it light and fits the NDA need. Any issues with that in core, or still leaning toward direnv?

[mikayla-maki]

@mkungla

I think we can do an approach similar to VSCode’s —use-data-dir CLI option for this use case. That way we’re not messing with the app id, and are covering all of the data we use in directories, while still hitting your use case :)