# inshellisense: IDE style autocomplete for bash, zsh, fish, pwsh and nushell

> Microsoft's inshellisense wraps your existing shell in a Node.js runtime that renders Fig autocomplete specs as a dropdown. It is a useful upgrade for interactive shell work, and a poor fit for locked-down or non-interactive environments.

**microsoft/inshellisense** — IDE style command line auto complete

- Repository: https://github.com/microsoft/inshellisense
- Stars: 10,715 · Forks: 256
- Language: TypeScript
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-inshellisense

## What inshellisense actually solves for shell users

Shell completion has always been uneven. Bash ships programmable completion, zsh has compsys, fish has its own generator, and each of them is maintained by a different community with a different idea of what a subcommand looks like. The result is that a flag you rely on in one shell may not appear in another, and tools with deep subcommand trees often get only partial coverage. inshellisense takes a different route: instead of asking each shell to describe its own CLI surface, it reads the Fig autocomplete spec collection, published as the @withfig/autocomplete package, and renders those specs in a terminal dropdown. The README states support for 600+ command line tools. The audience is anyone who lives in an interactive shell and wants the same kind of suggestion list an editor gives for a function signature. It is not a completion engine for scripts, and it is not a replacement for the shell's own completion system.

## How the runtime sits between your keystrokes and the shell

The architecture visible in the repository is a terminal emulator that hosts a shell. The package depends on @xterm/headless and @xterm/addon-unicode11, which is how a Node process can render and read a terminal grid without a GUI. When you run is, inshellisense starts a session on the current shell; the README lists exit as the way to stop it and is -c as a check for whether you are inside a session. Keybindings are captured only while suggestions are visible: tab accepts, the arrow keys move through the list, escape dismisses. Everything else passes through to the shell underneath. Configuration is a TOML file, and the repository points at src/utils/config.ts for its JSON schema, so the shape of the config is defined in code rather than only in prose. One design consequence worth naming: because inshellisense owns the rendering layer, it can style suggestions (boxBorderStyle, activeSuggestionBackgroundColor) in ways a shell's native completion cannot.

## Installing inshellisense and running a first session

The README recommends npm. The package name is @microsoft/inshellisense and the binary is exposed under both is and inshellisense. Note the engines field in package.json: Node >=18.0 <23.0.0, so a Node 23 or newer runtime is outside the declared range.

```bash
npm install -g @microsoft/inshellisense
is init
```

On macOS and Linux, Homebrew is the alternative path. The tap is added from the repository URL, then the formula is installed, then is init runs the same setup step.

```bash
brew tap microsoft/inshellisense https://github.com/microsoft/inshellisense
brew install inshellisense
is init
```

After installation the README says to run is doctor to verify the setup, then is to start a session. If you want inshellisense to start automatically in every new shell, append the init output to your shell config. For zsh that is a single redirect:

```bash
is init zsh >> ~/.zshrc
```

The equivalent commands are documented for bash, fish, pwsh, powershell, xonsh and nushell. For nushell the README uses is init nu piped into save $nu.env-path --append, which is a different shape from the other shells. One caveat the README states plainly: the inshellisense plugin has to be the last command in the config file. If a plugin manager or prompt initializer runs after it, the configuration can break. That ordering requirement is easy to violate on a machine where the config file is assembled from several sources.

## Where inshellisense stops: large cloud CLIs and shell config ordering

The README has a short section titled Unsupported Specs. It says the specs for az, gcloud and aws are not supported because of their large size. That is a real gap for cloud engineers, and it is exactly the category of tool where an autocomplete list helps most, since these CLIs have long subcommand paths and many flags. If your daily work is az group create or gcloud run deploy, inshellisense will not help with the parts you most want completed. The second limitation is structural rather than a missing feature: the tool inserts itself between your terminal and your shell, so it needs a working Node runtime in the foreground. On a jump host where you cannot install global npm packages, or in a CI job, there is nothing to adopt. The third is the ordering constraint already mentioned. The fourth is that alias expansion is documented only for bash and zsh, so fish, pwsh, xonsh and nushell users do not get that behaviour even though useAliases exists as a config key.

## inshellisense compared with your shell's built-in completion

The honest alternative is the completion system you already have. Bash's programmable completion and zsh's compsys are maintained alongside the shells themselves, need no extra process, and work in scripts and non-interactive contexts. They also handle completion for tools that never published a Fig spec, because the completion function ships with the tool or with the distribution. inshellisense's difference is the spec source: it renders suggestions from a shared, cross-shell spec package rather than from per-shell completion functions. That means consistent behaviour across bash, zsh, fish, pwsh, xonsh and nushell, and richer descriptions for the 600+ tools the specs cover. It also means the quality of a given tool's completion is bounded by whether someone wrote a spec for it. The two approaches are not mutually exclusive. Because inshellisense only captures keys while its suggestion list is visible, the shell's own completion still runs when inshellisense has nothing to show.

## Configuration, updates and the cost of keeping it current

The config file lives at ~/.inshellisenserc or, following the XDG spec, at $XDG_CONFIG_HOME/inshellisense/rc.toml, defaulting to ~/.config/inshellisense/rc.toml when XDG_CONFIG_HOME is unset, empty or not absolute. Generated resources moved to $XDG_DATA_HOME/inshellisense on new Unix-like installs, defaulting to ~/.local/share. Existing installations keep using ~/.inshellisense while that directory exists, and Windows keeps using it too. The README says is reinit migrates legacy resources to the XDG data directory, which is the command to run if you want the new layout rather than the old one. Updating is npm install -g @microsoft/inshellisense or brew upgrade inshellisense, followed by is reinit. The version history in the repository is short: 0.0.2, 0.0.3 and 0.0.4, with the latest released on 2026-09-11. The pre-1.0 version number is the honest signal here. Config keys and the on-disk layout have already changed once, and the migration path is a manual command rather than something automatic. Budget for reading release notes before upgrading a fleet of machines. The licence is MIT, which is permissive and imposes no copyleft obligation on your own code, but the project also asks contributors to sign a Microsoft CLA and points at a code of conduct. Those are contribution terms, not terms that bind users of the published package.

## Which shells and platforms inshellisense covers today

The README lists bash, zsh, fish, pwsh, powershell (Windows PowerShell), cmd, xonsh and nushell. Only cmd is marked experimental. Platform support is Windows, Linux and macOS. The repository carries a Formula/ directory alongside the npm package, which matches the two documented install paths. There is also a shell/ directory in the top-level listing, consistent with the per-shell init scripts the README's plugin section references. If you are choosing between shells on a new machine and want inshellisense to work, all of the listed shells are documented, but the alias expansion feature narrows that to bash and zsh. The keybinding defaults are matched against Node.js keypress events, so custom key names have to be spelled the way that API spells them, not the way your terminal emulator does.

## Conclusion

Adopt inshellisense if you spend most of your day in an interactive bash, zsh, fish, pwsh or nushell session and want Fig's spec coverage without switching terminals. Do not adopt it if you need the az, gcloud or aws CLIs covered, if your environment cannot run a Node.js 18 to 22 process in front of the shell, or if your shell config file has commands that must run after your prompt setup, since the README insists the plugin go last. Before rolling it out, run is doctor and check the output, then try is init on one machine and confirm the generated file lands where your shell actually reads it.

## FAQ

### Is autocomplete considered AI?

The README does not describe inshellisense as an AI system. It describes it as a terminal-native runtime for the Fig autocomplete spec collection, which renders suggestions from published specs for 600+ command line tools.

### How do I turn on autocomplete?

Install with npm install -g @microsoft/inshellisense and run is init, then run is to start a session on the current shell. To have it start automatically in every new shell, append the output of is init for your shell to that shell's config file.

### What is IntelliSense?

The README does not define IntelliSense. It uses the phrase IDE style autocomplete to describe what inshellisense provides for shells, and the package description in package.json repeats that wording.

### What is the use of autocomplete?

In inshellisense, autocomplete is a suggestion list shown as you type, with tab to accept the current suggestion, the arrow keys to move through the list, and escape to dismiss it. All other keys pass through to the shell.

## Sources

- [Issues](https://github.com/microsoft/inshellisense/issues)
- [License: MIT](https://github.com/microsoft/inshellisense/blob/main/LICENSE)
- [microsoft/inshellisense on GitHub](https://github.com/microsoft/inshellisense)
- [README](https://github.com/microsoft/inshellisense/blob/main/README.md)
- [Releases](https://github.com/microsoft/inshellisense/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-inshellisense