Is your feature request related to a problem? Please describe.
I'd like tasks to share Serena server and have each connection use appropriate permissions. for example, an implementation task and a review task. The implementation task could change code and memories and the reviewer could inspect files and follow references without making changes. These would be separate sessions of the same agent.
Sharing a server for the same working copy avoids starting duplicate language servers. I want to keep different Git worktrees on separate Serena servers because their files and state can differ, and Serena's active project is shared across connections.
Telling a reviewer “don't edit” or hiding editing tools in its client does not stop it from requesting an editing tool directly. I want Serena itself to enforce the difference.
Describe the solution you'd like
Add optional access tokens that let Serena distinguish between connections allowed only to read and those also allowed to edit. The application running Serena would supply the token checker through the MCP Python SDK's existing support, rather than Serena introducing its own login system.
When this feature is enabled, Serena should:
- Show each connection only the tools it is allowed to use.
- Reject a forbidden tool call before it runs, even if the client requests it directly.
- Check the permissions on every request, not just when a session starts. Missing, invalid, or revoked tokens must not grant access, nor should tokens with no Serena permissions.
Serena already classifies tools as editing or non-editing. These permissions would restrict Serena tools only, not an agent's terminal or other ways of editing files.
The application would still issue and revoke tokens, manage worktrees, and decide how many editing connections to allow.
Describe alternatives you've considered
Separate servers for every client duplicate startup and state. Prompts and hidden tools do not enforce permissions. A separate service in front of Serena could check access, but would also need to understand Serena's tool calls and maintain its own permission rules.
Additional context
Two local tests passed using my own serena-worktree-server launcher, a modified Serena server, and fastmcp-remote. They started real processes and checked that:
- Serena starts and lists tools successfully.
- Two readers can share the server with a writer. Readers see only non-editing tools, and a direct editing request is rejected without creating a file.
- The writer can edit, invalid tokens are rejected, and its token stops working after disconnect.
- A replacement writer can connect without restarting Serena while readers remain connected.
My launcher also rejected a second simultaneous writer; that policy is outside this request. Another 182 tests for the launcher and worktree setup passed across two runs.
tldr - requesting optional token checking and tool permissions enforced by Serena itself.
Is your feature request related to a problem? Please describe.
I'd like tasks to share Serena server and have each connection use appropriate permissions. for example, an implementation task and a review task. The implementation task could change code and memories and the reviewer could inspect files and follow references without making changes. These would be separate sessions of the same agent.
Sharing a server for the same working copy avoids starting duplicate language servers. I want to keep different Git worktrees on separate Serena servers because their files and state can differ, and Serena's active project is shared across connections.
Telling a reviewer “don't edit” or hiding editing tools in its client does not stop it from requesting an editing tool directly. I want Serena itself to enforce the difference.
Describe the solution you'd like
Add optional access tokens that let Serena distinguish between connections allowed only to read and those also allowed to edit. The application running Serena would supply the token checker through the MCP Python SDK's existing support, rather than Serena introducing its own login system.
When this feature is enabled, Serena should:
Serena already classifies tools as editing or non-editing. These permissions would restrict Serena tools only, not an agent's terminal or other ways of editing files.
The application would still issue and revoke tokens, manage worktrees, and decide how many editing connections to allow.
Describe alternatives you've considered
Separate servers for every client duplicate startup and state. Prompts and hidden tools do not enforce permissions. A separate service in front of Serena could check access, but would also need to understand Serena's tool calls and maintain its own permission rules.
Additional context
Two local tests passed using my own
serena-worktree-serverlauncher, a modified Serena server, andfastmcp-remote. They started real processes and checked that:My launcher also rejected a second simultaneous writer; that policy is outside this request. Another 182 tests for the launcher and worktree setup passed across two runs.
tldr - requesting optional token checking and tool permissions enforced by Serena itself.