SOPS Memory Editor

Encrypt and edit SOPS files using VS Code's native editor. .sops.yaml path rules—not a filename-extension allowlist—control the Encrypt and Decrypt actions. Embedded SOPS metadata determines encryption state. Decryption uses an in-memory virtual file with encrypted saves and no decrypted sidecar files.

Use

1. Install SOPS 3.10+ and make its keys/credentials available to the VS Code extension host. For SSH, WSL, or a dev container, install/configure SOPS there.
2. Install the built VSIX using Extensions → … → Install from VSIX.
3. Open a file in the editor. The extension checks its parent directories for .sops.yaml; a matching encrypted file gets a Decrypt editor-title action and Explorer context action. After decryption succeeds, its tab is replaced by a sops-decrypted: virtual file in the same editor group; the status bar shows SOPS: Decrypted. In the Command Palette, this is SOPS: Decrypt.
4. Edit normally, then press Ctrl/Cmd+S. The original file is replaced with ciphertext only after encryption succeeds. Native undo/redo, search/replace, multiple cursors, and syntax highlighting work normally.

Decrypted files open with a [SOPS] prefix in the tab title, even when file decorations are disabled. They also provide a SOPS: Decrypted tooltip and the theme's warning color; enable workbench.editor.decorations.colors in VS Code settings to display the color in tabs. The status bar shows an unlocked icon for the active decrypted file.

Normal Save encrypts back to the source file. VS Code's ordinary Save As can export the decrypted text; it does not create an encrypted copy.

Set sops.executablePath in user/remote settings if SOPS is not on the extension host's PATH. A trusted workspace is required.

Configuration and in-place encryption

• When a file becomes active in the editor, the extension walks up from its directory to the nearest .sops.yaml and checks creation_rules.path_regex. This works outside the workspace too, for dotfiles, extensionless files, and arbitrary suffixes. Paths are relative to the configuration directory, and matching uses an RE2 engine compatible with SOPS's Go-style expressions, including inline flags. A rule without path_regex matches every file in its scope. A nearer config overrides the parent even if none of its rules match.
• Matching files with SOPS metadata show Decrypt. Matching unencrypted files show Encrypt. A lightweight check recognizes the version and encrypted MAC in YAML/JSON, dotenv, or INI; SOPS itself validates the document when decrypting. The config itself never gets either action.
• Click Encrypt to encrypt the existing file in place, using its matching config rule. Save or discard unsaved edits first. A failed encryption, cancellation, or detected source change leaves the source intact. Editing the buffer while encryption runs cancels the operation.
• Actions follow the active file; Explorer actions are available for that same file. There is no workspace scan or directory exclusion list. Only the active source file is watched for action updates. Config files are not watched: after changing .sops.yaml, switch away from the file and back to refresh its actions. Encryption always reads the current config. Metadata alone does not make an unmatched file eligible for automatic actions. Explicit Command Palette decryption can still open an existing encrypted file.
• Like SOPS, automatic config lookup uses .sops.yaml, not .sops.yml. Unreadable files or invalid config rules are not offered an automatic encryption action. Invalid structured content is rejected by encryption without replacing the source.

Formats and binary files

Eligibility is exclusively config-based. Serialization follows SOPS conventions: YAML, JSON, dotenv (.env and *.env), and INI use their structured stores; other names use SOPS's binary store, which encrypts the entire payload into a JSON envelope. For example, .env.production, private-key.pem, and an extensionless file are supported as binary-store payloads, rather than excluded.

UTF-8 text inside a binary-store file is editable in the normal text editor. Actual binary data is exposed as exact bytes through the virtual filesystem, including NULs, non-UTF-8 bytes, and BOMs. VS Code's usual binary-file handling applies; use a binary-capable editor for non-text data. Binary-editor saves remain byte-preserving.

Plaintext handling

• A virtual filesystem supplies decrypted bytes to VS Code's native TextDocument. The extension never creates a plaintext copy beside the encrypted source or elsewhere on disk.
• SOPS receives plaintext through stdin and returns ciphertext through stdout. The extension never invokes SOPS's temporary-file editor mode.
• Temporary save files contain ciphertext only. No temporary policy files are created.
• Raw CLI/parser errors are suppressed because they can include secret values.
• VS Code owns the native document's recovery backups and may persist plaintext in its user-data directories. Other extensions can also access the decrypted document. This is not a strict guarantee that plaintext never reaches disk. Global backup, autosave, and history settings are left as configured; normal autosaves use the encrypted write path.

The extension does not claim to securely erase JavaScript strings from memory or control OS swap, crash dumps, clipboard persistence, or external credential tools.

Save behavior and scope

• Every encryption uses the current .sops.yaml for the source file. SOPS handles recipient backends, Shamir groups, and selective-encryption policies directly. Changing the config changes the recipients and rules used on the next save; embedded metadata is used for decryption, not to reconstruct an encryption policy. Shell recipient defaults and SOPS_CONFIG cannot override this behavior.
• Saving requires a matching config rule and encryption access to its recipients. Missing, invalid, or unmatched configuration leaves the existing ciphertext and editor contents intact. Decryption itself does not require a matching config.
• Saving generates a new data key. SOPS may normalize formatting and refresh all encrypted values; the current config determines which fields remain public.
• External changes reload clean documents; conflicting saves from dirty documents fail rather than silently overwrite the source. File: Revert File reloads and decrypts the file from disk.
• Language extensions that support virtual documents can provide additional features. Extensions restricted to file: URIs may not activate for sops-decrypted: documents.
• Maximum decrypted payload size: 16 MiB, for text or binary data. SOPS operations time out after two minutes. Untitled documents and source files on third-party virtual filesystems are not supported.

Develop and package

pnpm install --frozen-lockfile
pnpm test
pnpm run package

Use the pnpm version pinned in package.json. The hoisted install layout keeps VSCE's dependency discovery compatible with pnpm.

The tests require sops and age-keygen on PATH. They generate disposable fixtures and test configuration matching, config changes on save, metadata detection, encrypted editing, and exact binary round trips. pnpm run package creates sops-memory-editor-0.1.1.vsix.

pnpm run test:vscode tests the real native editor, encrypted saves, undo/redo, revert, conflicts, editor-driven parent lookup, config refresh on selection, and in-place encryption in a downloaded VS Code; Linux needs a display (for example, xvfb-run -a pnpm run test:vscode).