Skip to content
| Marketplace
Sign in
Visual Studio Code>Programming Languages>Ansible Vault & Project DoctorNew to Visual Studio Code? Get it now.
Ansible Vault & Project Doctor

Ansible Vault & Project Doctor

sellerkit

| (0) | Free
Edit Ansible Vault files without a decrypted copy in your project. Plus: why a module or role will not resolve.
Installation
Launch VS Code Quick Open (Ctrl+P), paste the following command, and press enter.
Copied to clipboard
More Info

Ansible Vault & Project Doctor

Edit encrypted files without a decrypted copy in your project.

Opening an Ansible Vault file, editing it, and saving it back encrypted

Open a vault file, and it opens decrypted, as an ordinary editor tab. Type. Save. It is encrypted again. Your project folder never holds the plaintext, so there is nothing to forget and nothing to accidentally commit.

That is the difference. Every other extension for this has you run a decrypt command, which rewrites the file in place and leaves real credentials sitting in your working tree until you remember to run encrypt again. People forget. Then production secrets are in a commit.

One thing to know

While an editor tab has unsaved changes, VS Code keeps its own backup of the tab's contents so nothing is lost in a crash. For a decrypted vault file that backup contains the plaintext, and it lives in VS Code's storage, not in your project:

~/Library/Application Support/Code/Backups/…   (macOS)
%APPDATA%\Code\Backups\…                      (Windows)

VS Code removes it as soon as you save or close the tab. No extension can turn this off for a normal text editor, and files.hotExit: "off" does not stop it either; both were measured, not assumed.

So: your repository never sees plaintext, which is the risk that actually bites people. An unsaved tab does leave a copy in VS Code's own folder until you save it. Save when you are done, and there is nothing left anywhere.

What it does

Open decrypted. Ansible Vault: Open Decrypted, or say yes when it notices you have opened an encrypted file. Saving re-encrypts, keeping the original header, so a 1.2 file keeps its vault id.

Encrypt a selection in place. Select a value, and it becomes an inline !vault block, indented the way ansible-vault encrypt_string writes it. This was asked for in September 2018 on the extension with 111,000 installs and is still open there.

Read one value without decrypting the file. Put the cursor on an inline !vault block and it tells you what it says.

It tells you when a setting is being ignored. ANSIBLE_COLLECTIONS_PATHS and COLLECTIONS_PATH look right and do nothing: current ansible-core reads only ANSIBLE_COLLECTIONS_PATH, and says nothing about the others. A project with the wrong spelling looks configured and behaves as though it is not. The report names the setting and the spelling that works.

It finds the password the way ansible does. ANSIBLE_VAULT_PASSWORD_FILE, vault_password_file in your ansible.cfg, and vault_identity_list with its labels matched against the vault id in the file's own header. On a machine that is already set up for ansible you are never asked for anything. "Plugin not respecting ANSIBLE_VAULT_PASSWORD_FILE" has been open elsewhere since 2019.

No Python, no ansible, no subprocess. The vault format is implemented directly, so this works in a container, on a fresh laptop, and on Windows, where the others need an ansible on PATH to do anything at all.

And: why will this module not resolve?

Ansible: Explain Collection and Role Paths reports which ansible.cfg won and by which rule, every directory searched in order, what was found in each, and what is shadowing what.

It resolves from the folder of the file you have open, not the first workspace folder, so the answer matches what you get in a terminal next to that playbook.

What it will not do

It never runs a program. It reads and writes files, and that is all.

It never deletes or renames a file of yours. A save is written to a temporary file beside the original and moved into place, so a save interrupted halfway cannot leave a broken payload where your secrets were.

It keeps the permissions the file already had, rather than deciding for you what a secrets file should be. A file you have made read-only stays read-only, and the save is refused instead.

Your password is held in memory for the window only. It is not written to VS Code's secret store, not synced, and not logged. Close the window and it is gone. A password file that is executable is reported, never run: running a program named in a config file, to get at a secret, is not an editor's job.

Nothing happens at startup. There is no scan, no watcher, no subprocess. The extension is inert until you ask it for something.

Is it right?

Checked against ansible-core itself, not against its own idea of the rules:

What we encrypt, ansible-vault decrypts yes, 1.1 and 1.2 with a vault id
What ansible-vault encrypts, we decrypt yes
A wrong password refused before decrypting, by HMAC
Module index vs ansible-doc --list 743 vs 743, no difference either way
Path resolution vs ansible-config dump 4 of 4 cases identical

Measured on ansible-core 2.19.12, against community.general, kubernetes.core, ansible.posix, containers.podman and fedora.linux_system_roles. The comparison is ansible-doc --list and ansible-config dump against what this extension reports, so it is a check anyone can repeat.

Free

Free, and there is nothing to buy inside it.

  • Contact us
  • Jobs
  • Privacy
  • Manage cookies
  • Terms of use
  • Trademarks
  • Your Privacy Choices
  • Consumer Health Privacy
© 2026 Microsoft