You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Include provider information in code actions #2188
For filtering purposes in the client, it would be useful for code actions to include information about its provider, similar to how diagnostics have an optional source field.
I think it's important to show a clear need and real examples from existing language servers before adding yet another string field with arbitrary data. Otherwise, we just introduce extra work for clients to support and display it somewhere.
For client-side filtering, there's already the kind field, which is explicitly documented as: The kind of the code action. Used to filter code actions.
For context, this topic originally came up in neovim/neovim#36028 (comment) about one of Neovim's APIs for filtering code actions that only exposes the CodeAction object and therefore didn't support filtering by client. The proposed solution - adding a field for the server to pass its own ID - is a dead end. There's no need to reference server IDs after the initialization handshake, since the client already tracks active servers and can identify them without extra RPC overhead.
The existing source field in diagnostics is often used by servers to specify the linting rule, which is actually useful to users and makes sense to keep as a separate field rather than concatenating it into the title string. The kind field already serves a similar purpose for code actions, and I don’t see any case where it wouldn't be sufficient or would justify adding another field.
Reacted by Justin M. Keyes, Sean Dewar and Dave Halter
Otherwise, we just introduce extra work for clients to support and display it somewhere.
There's no extra work that needs to be done. Editors can decide to just not use this field.
For client-side filtering, there's already the kind field, which is explicitly documented as: The kind of the code action. Used to filter code actions.
Well kind is A filter, the source could be another one. Multiple code action providers can (and often do) set the same kind, and so having the source could offer a more granular filtering.
I don't seem to be the only one that sees value in having the source in a code action. Mathias Fußenegger (@mfussenegger) also proposed it in #2020 (review) as a way to identify AI-generated code actions.
Otherwise, we just introduce extra work for clients to support and display it somewhere.
There's no extra work that needs to be done. Editors can decide to just not use this field.
Of course they can, but do they really want to? What I'm trying to say is that we should respect the work of both client and server developers and set a high bar for justifying additions to the spec. While the protocol should remain flexible, the minimal bar for adding anything should be at least a theoretical use case, or ideally a real-world LSP implementation that actually needs it.
Quoting you from Matrix:
I agree that adding arbitrary bluff is useless, but I think that for code actions it might be helpful. With AI taking over editor tooling I can imagine multiple models providing actions with the same kind/title/description but then the user might want to filter out by a given model
Thanks for the example - that's exactly what was missing. Having a clear picture of the feature's purpose helps raise new questions:
Should the field be an arbitrary string, or could the server predefine a set of allowed providers during init?
Should it only apply to code actions, or might other methods (like inline completions) need it too?
Should it be a top-level field in the response and named source? If it's provided without an LLMGenerated tag, what does the value actually mean? Maybe there is a reason to restrict to this specific domain.
And the only way to avoid guessing and choose the right design is to have at least some features and workflow requirements implemented - for example outside LSP in some editor. I may not be fully up to date with the latest trends, but it seems that no AI-powered editor or LSP server currently provides code actions from multiple sources. If such a scenario exists or emerges in the future, the appropriate way to address it would be to create a dedicated issue with title like: "Server X needs an LSP field to support feature Y in clients without a hack."
The source could also be helpful in sorting code actions,
where users might want to assign priorities to certain LSPs
I may be misunderstanding you here, but I want to emphasize again: servers and clients shouldn't use any fields after initialization to identify each other. If a client wants to provide an API to filter by server, it already has all the necessary information and should just expose it (like in case of Neovim). Even if a server were to provide this info in an field like source, a client cannot reliably depend on it because there's nothing forcing the server to a) provide it b) put its ID there.
I actually tend to close this. In most cases one server provides code actions for one language. IMO the source field would be always the same. Maria Solano (@MariaSolOs) do you have a compelling use case for this?
Here's an example from HLS. HLS has a plugin to run hlint, a Haskell linter. hlint can provide refactoring suggestions that fix some of its lint suggestions. So HLS provides:
Diagnostics from hlint (with the source set to hlint)
Quick fix code actions from hlint (no way to currently tag these as coming from hlint)
Why care? It would allow for client-side filtering decisions like "I am never interested in the refactoring suggestions from hlint, please just never show these to me" without requiring a server-side option to not send them.
So a bit niche, but I think useful for the same reason that source in diagnostics is somewhat useful.
This would be useful as an end-user to see what extension or LSP a quick-fix action is coming from. It would also be useful for debugging issues for users switching between linters (e.g. from ESLint to Oxlint) since they have similar quick fix options. If a project is switching from one linter to the other, it's hard to tell which LSP any given quick fix comes from and it may lead to confusing behaviors.
Activity
arkriny commentedon Oct 5, 2025
I think it's important to show a clear need and real examples from existing language servers before adding yet another string field with arbitrary data. Otherwise, we just introduce extra work for clients to support and display it somewhere.
For client-side filtering, there's already the
kindfield, which is explicitly documented as:The kind of the code action. Used to filter code actions.For context, this topic originally came up in neovim/neovim#36028 (comment) about one of Neovim's APIs for filtering code actions that only exposes the
CodeActionobject and therefore didn't support filtering by client. The proposed solution - adding a field for the server to pass its own ID - is a dead end. There's no need to reference server IDs after the initialization handshake, since the client already tracks active servers and can identify them without extra RPC overhead.The existing
sourcefield in diagnostics is often used by servers to specify the linting rule, which is actually useful to users and makes sense to keep as a separate field rather than concatenating it into the title string. Thekindfield already serves a similar purpose for code actions, and I don’t see any case where it wouldn't be sufficient or would justify adding another field.MariaSolOs commentedon Oct 5, 2025
There's no extra work that needs to be done. Editors can decide to just not use this field.
Well
kindis A filter, the source could be another one. Multiple code action providers can (and often do) set the same kind, and so having the source could offer a more granular filtering.I don't seem to be the only one that sees value in having the source in a code action. Mathias Fußenegger (@mfussenegger) also proposed it in #2020 (review) as a way to identify AI-generated code actions.
arkriny commentedon Oct 5, 2025
Of course they can, but do they really want to? What I'm trying to say is that we should respect the work of both client and server developers and set a high bar for justifying additions to the spec. While the protocol should remain flexible, the minimal bar for adding anything should be at least a theoretical use case, or ideally a real-world LSP implementation that actually needs it.
Quoting you from Matrix:
Thanks for the example - that's exactly what was missing. Having a clear picture of the feature's purpose helps raise new questions:
Should the field be an arbitrary string, or could the server predefine a set of allowed providers during init?
Should it only apply to code actions, or might other methods (like inline completions) need it too?
Should it be a top-level field in the response and named
source? If it's provided without anLLMGeneratedtag, what does the value actually mean? Maybe there is a reason to restrict to this specific domain.And the only way to avoid guessing and choose the right design is to have at least some features and workflow requirements implemented - for example outside LSP in some editor. I may not be fully up to date with the latest trends, but it seems that no AI-powered editor or LSP server currently provides code actions from multiple sources. If such a scenario exists or emerges in the future, the appropriate way to address it would be to create a dedicated issue with title like: "Server X needs an LSP field to support feature Y in clients without a hack."
I may be misunderstanding you here, but I want to emphasize again: servers and clients shouldn't use any fields after initialization to identify each other. If a client wants to provide an API to filter by server, it already has all the necessary information and should just expose it (like in case of Neovim). Even if a server were to provide this info in an field like
source, a client cannot reliably depend on it because there's nothing forcing the server to a) provide it b) put its ID there.dbaeumer commentedon Dec 9, 2025
I actually tend to close this. In most cases one server provides code actions for one language. IMO the source field would be always the same. Maria Solano (@MariaSolOs) do you have a compelling use case for this?
michaelpj commentedon Dec 29, 2025
Here's an example from HLS. HLS has a plugin to run
hlint, a Haskell linter.hlintcan provide refactoring suggestions that fix some of its lint suggestions. So HLS provides:hlint(with the source set tohlint)hlint(no way to currently tag these as coming fromhlint)Why care? It would allow for client-side filtering decisions like "I am never interested in the refactoring suggestions from
hlint, please just never show these to me" without requiring a server-side option to not send them.So a bit niche, but I think useful for the same reason that
sourcein diagnostics is somewhat useful.connorshea commentedon Jan 19, 2026
This would be useful as an end-user to see what extension or LSP a quick-fix action is coming from. It would also be useful for debugging issues for users switching between linters (e.g. from ESLint to Oxlint) since they have similar quick fix options. If a project is switching from one linter to the other, it's hard to tell which LSP any given quick fix comes from and it may lead to confusing behaviors.