# Go's gopls adds interactive refactoring and proposes a new cross-editor LSP capability Go's language server and VS Code extension can now ask developers for parameters during code actions, instead of guessing. The Go team has proposed making those multi-step dialogs part of LSP, but support outside the Go editor integration remains experimental. gopls 0.24.0 and VS Code Go 0.56.0 ship interactive refactorings for struct tags and interface implementations; the broader Language Server Protocol extension is still a proposal, with cross-file moves in preview. - Status: Active - Published: 2026-10-17T16:48:58+13:00 - Updated: 2026-10-17T16:48:58+13:00 - Categories: Web Development, Developer Tools - Tags: Developer tools, Go, Language Server Protocol, refactoring, VS Code - Canonical HTML: https://beyondthe.news/dossiers/gopls-interactive-refactoring-lsp-forms-v024-2026 ## What changed On October 16, 2026, the Go team announced interactive refactoring in gopls v0.24.0 and the official VS Code Go extension v0.56.0. The implementation introduces dynamic, multi-step prompts during language-server code actions, letting developers specify details that standard LSP actions cannot currently ask for. It builds on a proposed LSP extension developed with input from the Dart team; the protocol proposal is not an adopted cross-editor standard. ## Why it matters Traditional language-server refactors generally infer intent from code location or use editor-specific UI integrations. A shared way to ask for choices could allow the same language-server feature to work across editors, reduce bespoke editor integrations, and make automated refactors more reliable. Go developers can use the shipped actions now, but other languages and editors should not assume compatibility until the proposal is adopted and implemented. ## The change: code actions can ask questions Instead of unconditionally adding camelCase JSON tags, gopls can ask which struct tags to add or remove and which naming convention to apply. The implementation can also ask which interface a concrete type should implement, search matching symbols and generate method stubs, including for generic interfaces. ## The LSP gap it aims to close Standard LSP code actions generally accept no dynamic input from the user; rename has a specialised parameter path. The Go team's proposed interactive code-action protocol would allow a language server to describe a sequence of input forms and then produce edits, avoiding a separate UI implementation for every editor and language combination. The upstream design and Microsoft LSP issue remain under discussion. ## What's shipping and what's not The official Go blog identifies gopls v0.24.0 and vscode-go v0.56.0 as working implementations. The blog also describes tag and interface actions present since v0.23.0. Cross-file and cross-package Move Declaration is demonstrated as a preview for an upcoming release, not a generally available v0.24 feature. Change Signature and richer conflict-resolution prompts are future directions. ## Practical adoption and limits Go developers using the supported VS Code extension can test the new actions and review the generated edits, especially import cleanup, tag naming and interface signatures. The project has explored proof-of-concept clients for Neovim and Emacs, but editor support varies; developers should verify exact gopls and extension versions before relying on the workflow. ## Key details - Announcement dated October 16, 2026. - Interactive code actions available in gopls v0.24.0 and VS Code Go extension v0.56.0. - Configurable struct tag insertion/removal and generated interface implementations are demonstrated. - Protocol is a proposed LSP extension, not an accepted universal standard. - Move Declaration across packages is preview work for a future release. - Change Signature and interactive conflict resolution are roadmap items. ## Builder takeaways - Update gopls and the official VS Code Go extension together before testing interactive code actions. - Use tag-selection dialogs instead of accepting hard-coded JSON/camelCase defaults. - Review generated interface method stubs and compile/test before committing. - Do not assume other editors or language servers support the proposed LSP forms yet. - Track the LSP design issue and Go release notes before planning automation around preview refactorings. ## What to watch - Whether the LSP proposal is accepted or revised. - Adoption by Neovim, Emacs, Dart and other language servers. - Release of cross-package Move Declaration and Change Signature refactorings. - Compatibility and regression reports from real projects. ## Uncertainties - The proposed protocol may change during review. - Not all Go editors support the interaction today. - The release announcement does not establish independent productivity gains. ## Sources - [Interactive refactoring in gopls](https://go.dev/blog/interactive-refactoring) — Go Team · primary announcement · 2026-10-16T00:00:00+13:00. Shipped version requirements, demos and roadmap. - [LSP Interactive Code Actions design proposal](https://go.googlesource.com/proposal/+/refs/heads/master/design/76331-lsp-interactive-refactoring.md) — Go proposal repository · primary technical design. Protocol mechanics, limitations and alternative designs. - [Support refactors that require user input/options #1164](https://github.com/microsoft/language-server-protocol/issues/1164) — Microsoft Language Server Protocol issue tracker · primary standards discussion. Proposal status and cross-ecosystem discussion.