---
title: "Get code actions"
method: POST
path: "/v1/devboxes/{id}/lsp/code-actions"
tags: ["ts-ls"]
---

# Get code actions

`POST /v1/devboxes/{id}/lsp/code-actions`

Get code actions for a part of a document.
This method calls the `getCodeActions` method of the `LanguageService` class, which in turn
communicates with the TypeScript language server to retrieve code actions for a given document.
https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_codeAction

## Path parameters

- `id` string, required

## Request body

- CodeActionsRequestBody
  - `context` CodeActionContext — Contains additional diagnostic information about the context in which a {@link CodeActionProvider.provideCodeActions code action} is run. The CodeActionContext namespace provides helper functions to work with {@link CodeActionContext} literals.
    - `diagnostics` Diagnostic[], required — An array of diagnostics known on the client side overlapping the range provided to the `textDocument/codeAction` request. They are provided so that the server knows which errors are currently presented to the user for the given range. There is no guarantee that these accurately reflect the error state of the resource. The primary parameter to compute code actions is the provided range.
      - `range` Range, required — A range in a text document expressed as (zero-based) start and end positions. If you want to specify a range that contains a line including the line ending character(s) then use an end position denoting the start of the next line. For example: ```ts { start: { line: 5, character: 23 } end : { line 6, character : 0 } } ``` The Range namespace provides helper functions to work with {@link Range} literals.
        - `start` Position, required — Position in a text document expressed as zero-based line and character offset. Prior to 3.17 the offsets were always based on a UTF-16 string representation. So a string of the form `a𐐀b` the character offset of the character `a` is 0, the character offset of `𐐀` is 1 and the character offset of b is 3 since `𐐀` is represented using two code units in UTF-16. Since 3.17 clients and servers can agree on a different string encoding representation (e.g. UTF-8). The client announces it's supported encoding via the client capability [`general.positionEncodings`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#clientCapabilities). The value is an array of position encodings the client supports, with decreasing preference (e.g. the encoding at index `0` is the most preferred one). To stay backwards compatible the only mandatory encoding is UTF-16 represented via the string `utf-16`. The server can pick one of the encodings offered by the client and signals that encoding back to the client via the initialize result's property [`capabilities.positionEncoding`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#serverCapabilities). If the string value `utf-16` is missing from the client's capability `general.positionEncodings` servers can safely assume that the client supports UTF-16. If the server omits the position encoding in its initialize result the encoding defaults to the string value `utf-16`. Implementation considerations: since the conversion from one encoding into another requires the content of the file / line the conversion is best done where the file is read which is usually on the server side. Positions are line end character agnostic. So you can not specify a position that denotes `\r|\n` or `\n|` where `|` represents the character offset. The Position namespace provides helper functions to work with {@link Position} literals.
          - `line` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
          - `character` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
        - `end` Position, required — Position in a text document expressed as zero-based line and character offset. Prior to 3.17 the offsets were always based on a UTF-16 string representation. So a string of the form `a𐐀b` the character offset of the character `a` is 0, the character offset of `𐐀` is 1 and the character offset of b is 3 since `𐐀` is represented using two code units in UTF-16. Since 3.17 clients and servers can agree on a different string encoding representation (e.g. UTF-8). The client announces it's supported encoding via the client capability [`general.positionEncodings`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#clientCapabilities). The value is an array of position encodings the client supports, with decreasing preference (e.g. the encoding at index `0` is the most preferred one). To stay backwards compatible the only mandatory encoding is UTF-16 represented via the string `utf-16`. The server can pick one of the encodings offered by the client and signals that encoding back to the client via the initialize result's property [`capabilities.positionEncoding`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#serverCapabilities). If the string value `utf-16` is missing from the client's capability `general.positionEncodings` servers can safely assume that the client supports UTF-16. If the server omits the position encoding in its initialize result the encoding defaults to the string value `utf-16`. Implementation considerations: since the conversion from one encoding into another requires the content of the file / line the conversion is best done where the file is read which is usually on the server side. Positions are line end character agnostic. So you can not specify a position that denotes `\r|\n` or `\n|` where `|` represents the character offset. The Position namespace provides helper functions to work with {@link Position} literals.
          - `line` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
          - `character` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
      - `severity` 1 | 2 | 3 | 4 — The diagnostic's severity.
      - `code` union — The diagnostic's code, which usually appear in the user interface.
        - number, double — Defines an integer in the range of -2^31 to 2^31 - 1.
        - string
      - `codeDescription` CodeDescription — Structure to capture a description for an error code. The CodeDescription namespace provides functions to deal with descriptions for diagnostic codes.
        - `href` string, required — A tagging type for string properties that are actually URIs
      - `source` string — A human-readable string describing the source of this diagnostic, e.g. 'typescript' or 'super lint'. It usually appears in the user interface.
      - `message` string, required — The diagnostic's message. It usually appears in the user interface
      - `tags` DiagnosticTag[] — Additional metadata about the diagnostic.
      - `relatedInformation` DiagnosticRelatedInformation[] — An array of related diagnostic information, e.g. when symbol-names within a scope collide all definitions can be marked via this property.
        - `location` Location, required — Represents a location inside a resource, such as a line inside a text file. The Location namespace provides helper functions to work with {@link Location} literals.
          - `uri` string, required — A tagging type for string properties that are actually document URIs.
          - `range` Range, required — A range in a text document expressed as (zero-based) start and end positions. If you want to specify a range that contains a line including the line ending character(s) then use an end position denoting the start of the next line. For example: ```ts { start: { line: 5, character: 23 } end : { line 6, character : 0 } } ``` The Range namespace provides helper functions to work with {@link Range} literals.
            - `start` Position, required — Position in a text document expressed as zero-based line and character offset. Prior to 3.17 the offsets were always based on a UTF-16 string representation. So a string of the form `a𐐀b` the character offset of the character `a` is 0, the character offset of `𐐀` is 1 and the character offset of b is 3 since `𐐀` is represented using two code units in UTF-16. Since 3.17 clients and servers can agree on a different string encoding representation (e.g. UTF-8). The client announces it's supported encoding via the client capability [`general.positionEncodings`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#clientCapabilities). The value is an array of position encodings the client supports, with decreasing preference (e.g. the encoding at index `0` is the most preferred one). To stay backwards compatible the only mandatory encoding is UTF-16 represented via the string `utf-16`. The server can pick one of the encodings offered by the client and signals that encoding back to the client via the initialize result's property [`capabilities.positionEncoding`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#serverCapabilities). If the string value `utf-16` is missing from the client's capability `general.positionEncodings` servers can safely assume that the client supports UTF-16. If the server omits the position encoding in its initialize result the encoding defaults to the string value `utf-16`. Implementation considerations: since the conversion from one encoding into another requires the content of the file / line the conversion is best done where the file is read which is usually on the server side. Positions are line end character agnostic. So you can not specify a position that denotes `\r|\n` or `\n|` where `|` represents the character offset. The Position namespace provides helper functions to work with {@link Position} literals.
              - …
            - `end` Position, required — Position in a text document expressed as zero-based line and character offset. Prior to 3.17 the offsets were always based on a UTF-16 string representation. So a string of the form `a𐐀b` the character offset of the character `a` is 0, the character offset of `𐐀` is 1 and the character offset of b is 3 since `𐐀` is represented using two code units in UTF-16. Since 3.17 clients and servers can agree on a different string encoding representation (e.g. UTF-8). The client announces it's supported encoding via the client capability [`general.positionEncodings`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#clientCapabilities). The value is an array of position encodings the client supports, with decreasing preference (e.g. the encoding at index `0` is the most preferred one). To stay backwards compatible the only mandatory encoding is UTF-16 represented via the string `utf-16`. The server can pick one of the encodings offered by the client and signals that encoding back to the client via the initialize result's property [`capabilities.positionEncoding`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#serverCapabilities). If the string value `utf-16` is missing from the client's capability `general.positionEncodings` servers can safely assume that the client supports UTF-16. If the server omits the position encoding in its initialize result the encoding defaults to the string value `utf-16`. Implementation considerations: since the conversion from one encoding into another requires the content of the file / line the conversion is best done where the file is read which is usually on the server side. Positions are line end character agnostic. So you can not specify a position that denotes `\r|\n` or `\n|` where `|` represents the character offset. The Position namespace provides helper functions to work with {@link Position} literals.
              - …
        - `message` string, required — The message of this related diagnostic information.
      - `data` unknown
    - `only` CodeActionKind[] — Requested kind of actions to return. Actions not of this kind are filtered out by the client before being shown. So servers can omit computing them.
    - `triggerKind` 1 | 2 — The reason why code actions were requested.
  - `range` Range — A range in a text document expressed as (zero-based) start and end positions. If you want to specify a range that contains a line including the line ending character(s) then use an end position denoting the start of the next line. For example: ```ts { start: { line: 5, character: 23 } end : { line 6, character : 0 } } ``` The Range namespace provides helper functions to work with {@link Range} literals.
    - `start` Position, required — Position in a text document expressed as zero-based line and character offset. Prior to 3.17 the offsets were always based on a UTF-16 string representation. So a string of the form `a𐐀b` the character offset of the character `a` is 0, the character offset of `𐐀` is 1 and the character offset of b is 3 since `𐐀` is represented using two code units in UTF-16. Since 3.17 clients and servers can agree on a different string encoding representation (e.g. UTF-8). The client announces it's supported encoding via the client capability [`general.positionEncodings`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#clientCapabilities). The value is an array of position encodings the client supports, with decreasing preference (e.g. the encoding at index `0` is the most preferred one). To stay backwards compatible the only mandatory encoding is UTF-16 represented via the string `utf-16`. The server can pick one of the encodings offered by the client and signals that encoding back to the client via the initialize result's property [`capabilities.positionEncoding`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#serverCapabilities). If the string value `utf-16` is missing from the client's capability `general.positionEncodings` servers can safely assume that the client supports UTF-16. If the server omits the position encoding in its initialize result the encoding defaults to the string value `utf-16`. Implementation considerations: since the conversion from one encoding into another requires the content of the file / line the conversion is best done where the file is read which is usually on the server side. Positions are line end character agnostic. So you can not specify a position that denotes `\r|\n` or `\n|` where `|` represents the character offset. The Position namespace provides helper functions to work with {@link Position} literals.
      - `line` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
      - `character` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
    - `end` Position, required — Position in a text document expressed as zero-based line and character offset. Prior to 3.17 the offsets were always based on a UTF-16 string representation. So a string of the form `a𐐀b` the character offset of the character `a` is 0, the character offset of `𐐀` is 1 and the character offset of b is 3 since `𐐀` is represented using two code units in UTF-16. Since 3.17 clients and servers can agree on a different string encoding representation (e.g. UTF-8). The client announces it's supported encoding via the client capability [`general.positionEncodings`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#clientCapabilities). The value is an array of position encodings the client supports, with decreasing preference (e.g. the encoding at index `0` is the most preferred one). To stay backwards compatible the only mandatory encoding is UTF-16 represented via the string `utf-16`. The server can pick one of the encodings offered by the client and signals that encoding back to the client via the initialize result's property [`capabilities.positionEncoding`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#serverCapabilities). If the string value `utf-16` is missing from the client's capability `general.positionEncodings` servers can safely assume that the client supports UTF-16. If the server omits the position encoding in its initialize result the encoding defaults to the string value `utf-16`. Implementation considerations: since the conversion from one encoding into another requires the content of the file / line the conversion is best done where the file is read which is usually on the server side. Positions are line end character agnostic. So you can not specify a position that denotes `\r|\n` or `\n|` where `|` represents the character offset. The Position namespace provides helper functions to work with {@link Position} literals.
      - `line` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
      - `character` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
  - `uri` string, required

## Response `200`

A list of code actions.

- union[]
  - union
    - BaseCodeAction
      - `kind` string
      - `isPreferred` boolean
      - `command` BaseCommand
        - `arguments` unknown[]
          - unknown
        - `command` string, required
        - `title` string, required
      - `edit` BaseWorkspaceEdit
        - `changes` RecordStringTextEditArray — Construct a type with a set of properties K of type T
      - `title` string, required
    - BaseCommand
      - `arguments` unknown[]
        - unknown
      - `command` string, required
      - `title` string, required

---

[API](https://skmtc.dev/runloopai/apis/runloop-api.md) · [All operations](https://skmtc.dev/runloopai/apis/runloop-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/runloopai/runloop-api/revisions/0cb966ca566f/schema)