Skip to content

Feature Request: Support for marking custom extension parameters as sensitive (trace-safe) #2249

Open

Description

@sratz

Context

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

Activity

  1. isidorn commented on May 4, 2026

    @isidorn

    Dirk Bäumer (@dbaeumer) could you help our friends from SAP? I know you are on your long vacation - so when you get back 🙏

  2. defenderfaith91-del commented on May 5, 2026

    @defenderfaith91-del
  3. dbaeumer commented on May 13, 2026

    @dbaeumer
    Member

    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.

  4. sratz commented on May 13, 2026

    @sratz
    Author

    But this would need support from every client.

    Yes, as outlined in the proposal

    • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature-requestRequest for new features or functionalityhelp wantedIssues identified as good community contribution opportunities

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions