GhostText: editing browser text fields in Sublime Text, VS Code, Emacs, Vim or Neovim

The problem GhostText solves: long-form writing in a browser textarea

Browser text fields are hostile to long writing. A comment box, a GitHub issue, a CMS body field or a support ticket form gives you a few lines of visible height, no keybindings you configured, no file on disk, and no spell checker you trust. People work around this by drafting elsewhere and pasting, which loses the connection between the draft and the field.

GhostText closes that gap in the other direction. You keep the browser field as the source of truth and attach an editor to it, so the text you compose in the editor appears in the field as you type, and edits made in the field come back to the editor. The README states the intent in one line: use your text editor to write in your browser, with everything typed in the editor instantly updated in the browser and vice versa.

The audience is narrow and specific. This is for developers and technical writers who already have a configured editor and want its keybindings, macros, snippets, multiple cursors and external tooling applied to text that must end up in a web form. It is not a note-taking app, not a clipboard manager, and not a way to sync files.

How the connection works: a browser extension plus an editor plugin over a local WebSocket

GhostText is two halves that must both be installed. The browser side is an extension published on the Chrome Web Store, Mozilla Add-ons and the Mac App Store; the README notes the Chrome build is also compatible with Edge and Opera. The editor side is a separate plugin per editor, and the README links one for Sublime Text, VS Code, Emacs (atomic-chrome on MELPA), Vim (vim-ghost), Neovim (nvim-ghost.nvim), Helix (helix-ghost) and Acme (Ghost).

The repository keeps a PROTOCOL.md at the top level, which is the strongest signal about the architecture: the wire format between extension and plugin is specified rather than left implicit, which is what allows third parties to write plugins for editors the maintainer does not use. The plugins are not vendored into this repository, so their release cadence is independent of the extension's.

The codebase itself is a browser extension built with Parcel from source/manifest.json into a distribution directory, with xo for linting. Its runtime dependencies are small and webext-flavoured: one-event, webext-base-css, webext-options-sync and webext-permission-toggle. Nothing in the manifest suggests a remote service. The sync path is local: extension and editor plugin talk to each other on the same machine. That matters for anyone evaluating it against cloud-based writing tools, because the text does not need to leave the machine to be synced, though the browser extension still runs with whatever page permissions it requests.

Installing GhostText and opening a field in your editor

Installation is two steps in the order the README gives. First install the browser extension for Chrome, Firefox or Safari from the linked store. Then install the plugin for your editor: GhostText from Package Control for Sublime Text, fregante.ghost-text from the VS Code Marketplace, atomic-chrome from MELPA for Emacs, vim-ghost for Vim, nvim-ghost.nvim for Neovim, helix-ghost for Helix, or Ghost for Acme.

The extensions ship through their stores, so there is no install command to run for normal use. What you can run is this repository itself, which builds the browser extension from source. The package.json declares Node >= 24 and these scripts:

npm install
npm run build
npm run watch

npm run build runs pre:build first, which removes the distribution directory and runs pre-build.mjs, then Parcel builds source/manifest.json with --no-cache and --no-source-maps into distribution. npm run watch does the same build in watch mode with --no-hmr. npm test runs xo followed by the build, so a lint failure stops the build. There is also a Safari path: pack:safari invokes xcodebuild against safari/GhostText.xcodeproj, and prepare:safari runs safari/prepare-release.sh.

For a first real use, the package.json points the web-ext runner at a test page:

"webExt": {
	"sourceDir": "distribution",
	"run": {
		"startUrl": [
			"https://ghosttext.fregante.com/test/"
		]
	}
}

Open that test page, click into its field, and the editor plugin should take over the buffer. If nothing happens, the README sends you to the troubleshooting page at ghosttext.fregante.com/troubleshooting/ rather than documenting failure modes inline.

What GhostText does not do, and when it is the wrong tool

The project is deliberately small, and the gaps follow from that. There is no server component, so there is nothing to self-host for a team and no shared state between machines. Two people cannot attach to the same field. There is no history, no versioning, no undo that spans both sides beyond whatever each application provides on its own.

The plugin surface is the real constraint. Because each editor implementation lives in its own repository, the quality and maintenance of your editor's plugin is not governed by this project's release cadence. The README lists supported editors; anything else needs a plugin written against PROTOCOL.md. If you use an editor outside that list, GhostText is the wrong tool until someone writes the other half.

Extension permissions are the second constraint. A browser extension that reads and writes text fields on pages needs access to those pages, and the repository includes a privacy-policy.md, which tells you the project treats data handling as something to state explicitly rather than assume. If your environment forbids browser extensions, or you cannot grant a content script access to the sites you write on, the whole approach fails at step one. And for short text, a one-line comment or a search box, the round trip through an editor costs more than it saves.

Alternatives and the difference in approach

The closest alternative is not another extension but the browser's own text handling: draft in a local file, then paste. That keeps your editor tooling and requires no extension, but it breaks the live link. GhostText's whole value is that the field and the buffer are the same text at the same time, so paste-based workflows are a different category, not a cheaper version of the same thing.

For people who want a browser-based editing surface with more structure, full web IDEs and cloud notebooks offer collaboration and persistence, at the cost of moving the text to a service and giving up your local editor configuration. GhostText keeps the local editor and gives up collaboration entirely.

Within the editor-plugin space, the meaningful comparison is between the plugins themselves. Emacs users get atomic-chrome, Vim users get vim-ghost, Neovim users get nvim-ghost.nvim, and VS Code users get fregante.ghost-text from the same maintainer as the extension. Those differ in how they open a buffer, how they handle multiple simultaneous fields and how actively they are maintained, and none of that is decided by this repository. If you are choosing an editor partly for GhostText support, evaluate the plugin's own repository, not this one.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-05-13. The most recent release listed is 26.5.12 on 2026-05-12, following 24.8.10 in August 2024 and 24.7.6 in July 2024. That gap between the 2024 releases and the 2026 release is worth noting if you depend on a store build: the extension is delivered through Chrome Web Store, Mozilla Add-ons and the Mac App Store, so the version you actually run is whatever those stores have approved, which can lag the repository.

Upgrade cost is low by design. There is no server, no database and no config file format to migrate. The extension updates through the store; the editor plugin updates through its own package manager (Package Control, the VS Code Marketplace, MELPA, or the plugin's repository). The risk of an upgrade is a protocol mismatch between a new extension and an old plugin, which is exactly the class of problem PROTOCOL.md exists to make debuggable.

The licence is MIT, copyright Federico Brigante. MIT permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the extent of what the repository states; it says nothing about the licence terms of the individual editor plugins, which are separate projects with their own licences, and nothing about the store terms that apply to the published extensions. If you are redistributing a build of the extension inside a product, check the plugin licences separately. This is not legal advice.

Editorial conclusion

GhostText is for people who already live in an editor and resent composing long text in a textarea: install the browser extension plus the plugin for your editor, then open the GhostText test page the project ships before trusting it with anything long. It is not for you if your editor has no plugin in the list (the README names Sublime Text, VS Code, Emacs, Vim, Neovim, Helix and Acme) or if you cannot install a browser extension at all. Verify first that your editor's plugin is still receiving releases, because the protocol is documented in PROTOCOL.md but each editor implementation is maintained separately from this repository.

Frequently asked questions

Official sources

1. fregante/GhostText on GitHub
2. License: MIT
3. Project website
4. README
5. Releases