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
Feature Request: Support for marking custom extension parameters as sensitive (trace-safe) #2249
We are building a language server that authenticates against external systems. Credentials (bearer tokens, username/password pairs) need to be provided by the user via the language client (e.g. VS Code) and transmitted to the language server via a custom LSP extension.
Problem
The vscode-languageclient library (and likely other client implementations) supports enabling a low-level JSON-RPC traffic trace, which can log the full payload of every request, response, and notification to an output channel (in VS Code, via "<id>.trace.server": "verbose" setting). This means any credentials passed as parameters in a custom extension request would appear in plain text in that output, which is a serious security issue.
We searched the specification and found no way to mark a parameter or an entire request/notification as sensitive, to signal that its content must be redacted or suppressed in such trace outputs.
Question / Request
Is there an existing convention or workaround for this that we may have missed?
If not, is this something worth addressing in the spec? For example via:
a way to mark a parameter / notification / request as sensitive
a client capability that the server can inspect to determine whether the client guarantees redaction of sensitive parameters in traces. This would allow the server to gracefully disable functionality that requires sensitive data when talking to a client that cannot provide that guarantee
Adding this on a parameter level is some sort of overkill. I would mark a whole request / notification as not traceable on the param level.
An alternative would be to add support to the request / notification type definition to trace itself. Then a password could be printed as ******. But this would need support from every client.
a client capability that the server can inspect to determine whether the client guarantees redaction of sensitive parameters in traces. This would allow the server to gracefully disable functionality that requires sensitive data when talking to a client that cannot provide that guarantee
any solution would require client support -- at minimum an "I am aware of a sensitivity flag and will ensure no tracing/logging on my end" capability that the server can check against.
Activity
isidorn commentedon May 4, 2026
Dirk Bäumer (@dbaeumer) could you help our friends from SAP? I know you are on your long vacation - so when you get back 🙏
defenderfaith91-del commentedon May 5, 2026
dbaeumer commentedon May 13, 2026
There is no workaround for this right now.
Adding this on a parameter level is some sort of overkill. I would mark a whole request / notification as not traceable on the param level.
An alternative would be to add support to the request / notification type definition to trace itself. Then a password could be printed as
******. But this would need support from every client.sratz commentedon May 13, 2026
Yes, as outlined in the proposal
any solution would require client support -- at minimum an "I am aware of a sensitivity flag and will ensure no tracing/logging on my end" capability that the server can check against.