Change:
execute(command: 'docCommentTemplate', args: Proto.FileLocationRequestArgs, token?: CancellationToken): Promise<Proto.DocCommandTemplateResponse>; execute(command: 'getApplicableRefactors', args: Proto.GetApplicableRefactorsRequestArgs, token?: CancellationToken): Promise<Proto.GetApplicableRefactorsResponse>; execute(command: 'getEditsForRefactor', args: Proto.GetEditsForRefactorRequestArgs, token?: CancellationToken): Promise<Proto.GetEditsForRefactorResponse>; <ins> execute(command: 'applyCodeActionCommand', args: Proto.ApplyCodeActionCommandRequestArgs, token?: CancellationToken): Promise<Proto.ApplyCodeActionCommandResponse>; </ins> // execute(command: 'compileOnSaveAffectedFileList', args: Proto.CompileOnSaveEmitFileRequestArgs, token?: CancellationToken): Promise<Proto.CompileOnSaveAffectedFileListResponse>; // execute(command: 'compileOnSaveEmitFile', args: Proto.CompileOnSaveEmitFileRequestArgs, token?: CancellationToken): Promise<any>; execute(command: string, args: any, expectedResult: boolean | CancellationToken, token?: CancellationToken): Promise<any>;

Discussion:
This would enable Microsoft/TypeScript. I am mostly describing changes to in the TypeScript repository here. we discussed this today. The returned in a code action request may include a list of commands. A code action may even have an empty list and consist of only a command. We could choose specify that must an of commands, although I'm not sure if that's worth bothering with. If the code action is accepted, the editor must send the commands back to the language service to actually be carried out. This means needing a new request type, "applyCodeFixCommand". This looks like: The contents of will just be what was sent to the editor. (Typically this will include a "type" field so the language service can dispatch on the type of action.) The language service should send a response when the action is complete. I'm thinking we can just reuse the field for error reporting and for a successful response. (Currently the field is documented to only be used if is false.) We could put that in the body, but then it seems redundant.
This proposed TS API changes seem good to me. I don't see any issues implementing this on our side. We'll just need to figure out how best to surface the success / failure messages to users Let me know when the TS part lands in a nightly build so that I can try prototyping this
If we put this in a nightly build, people will start seeing codefixes that don't work. Could you check out a branch instead?
Sure, sounds good
You can checkout and build the branch from the TypeScript repository. If you include in a file and it is an unused identifier, we'll give you a code fix that comes with a command to write a file . (It also replaces the file content so you can verify that at least that works.)
Thanks I'll open a PR on our side shortly. A few quick notes: Looks like is currently using instead of for the key. The name makes more sense to me Also, I get this error when I try to run the command:
Here's the PR:
I pushed a quick fix of those two issues -- changed the name from "action" to "command" and remembered to write to a file rather than to a directory.
Ok, the fix looks good.

I see the d.ts file being created now
Any reason this couldn't land in nightly so I can experiment with it? Regular users won't see anything until we actually add something in TypeScript master that uses this.
We're getting ready for release currently but I can check this in once we branch off for the September release. This code in its current state won't compile until we pick up a new * file from TypeScript, but we can sprinkle in some casts to work around this until then