Introduce Unified API Key Generation, Storage, and Authentication for MCP for Unity

[Jordonh18]

This pull request introduces a unified API key management system for MCP for Unity, enabling secure authentication across server processes, HTTP, and WebSocket transports. The changes ensure the API key is generated, persisted, and surfaced in the UI, and update configuration and connection logic to require and utilize the key. The most important changes are grouped below.

Authentication and API Key Management

• Added new AuthPreferencesUtility class to handle API key generation, storage (EditorPrefs and disk), and retrieval, ensuring the API key is always available and consistent between client and server.
• Updated EditorPrefKeys to include a constant for storing the API key.
• Ensured the API key is created and persisted when launching the local HTTP server, so both the server and clients share the same key.
• WebSocket transport now sends the API key in both X-API-Key and Authorization headers during handshake, with improved error handling for authentication failures.

User Interface Enhancements

• Added UI components to display, copy, and regenerate the API key in the connection settings window (McpConnectionSection.uxml and code-behind), making it easy for users to manage their API key. [1] [2] [3] [4] [5] [6] [7]

Configuration and Server Launch Updates

• Updated manual config JSON builder logic to always require the API key for HTTP transport, removing legacy authorization and adding a prompt for the API key in the config. [1] [2] [3] [4]
• Improved server launch command construction to properly quote arguments and ensure the API key is available before starting the server. [1] [2]

Meta and Miscellaneous

• Added .meta files for new assets and folders to support Unity's asset tracking. [1] [2]

These changes collectively provide a more secure and user-friendly authentication flow for MCP for Unity, ensuring all clients and servers use a shared API key and making key management straightforward for users.

[coderabbitai]

Important

Review skipped

Draft detected.

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.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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 and usage tips.}

[dsarno]

@Jordonh18 Thanks for your contribution here. This seems like a good idea for hardening the networking. But it does add complexity and maintenance, and more room for bugs and potential security issues down the road. So I guess my question is -- why now for this? Do you have a use case where you see more people wanting to run their own server remotely? It seems the vast majority of users are running locally at this point.

[Jordonh18]

The project already has extensive remote deployment infrastructure. The v8 migration explicitly redesigned the architecture to support remote scenarios. WebSocket communication replaced port 6400 specifically because a remote HTTP server wouldn't have access to a user's port 6400. The Docker Compose configuration binds to 0.0.0.0, and the documentation explicitly lists use cases like "run the MCP server in the cloud," "dedicated server all your personal computers connect to," and "hosted by various MCP marketplaces." These aren't theoretical features, they're documented capabilities of the current architecture.

The security gap is that these remote deployment features exist without any authentication mechanism. Right now, anyone deploying the Docker container or running the HTTP server on a network exposes full Unity Editor control to anyone who can reach that endpoint. This isn't hypothetical. The documented use cases (team servers, cloud hosting, marketplace distribution) all require access control. Without authentication, users must choose between using the remote features unsafely or not using them at all, which seems wasteful given the significant architectural work that went into enabling them.

A minimal API key implementation would be optional by default, preserving backward compatibility for local-only users. It would only activate when UNITY_MCP_API_KEY is set. This protects the users who are already deploying remotely (as your architecture enables and documents) without adding complexity for the majority running locally.

This is a long-term improvement, and I’m fully aware there are plenty of factors to weigh up. I’d really like to hear any concerns or arguments against it. I’m always open to feedback on anything I propose.

[dsarno]

Hi, it makes sense, and I'm not against it in principle. In part this is a question of bandwidth (no pun intended). There are only a few active maintainers here, and I'm not a networking specialist -- so I need to look at it more closely, even though I realize it's straightforward. We should get feedback from other maintainers like @msanatan and @Scriptwonder too.

It's true the http upgrade was done in anticipation of a remote option, so that's a clear point in its favor -- or rather, a must-have for that use case.

I guess if it ends up being easy enough to do this (meaning potential downsides, maintenance-costs and risks clearly understood by all), then it doesn't matter if most people won't use it yet, it should just be in there.

I just want to be deliberate and get everyone's input before we go full network mode.