SecEdit

SecEdit transparently edits SecNote and SecByte encrypted files in Visual Studio Code without creating a plaintext file on disk.

Supported containers

• *.secnote through secnote >= 1.4.0
• *.secbyte through secbyte >= 1.6.3

Examples:

• README.md.secnote opens as Markdown.
• app.ts.secbyte opens as TypeScript.
• photo.jpg.secbyte opens in VS Code's built-in Image Preview.
• video.mp4.secbyte opens in VS Code's built-in Video Preview.
• data.csv.secbyte opens in ReprEng CSV when that extension is installed, otherwise as text.
• document.pdf.secbyte opens in tomoki1207.pdf when installed, otherwise falls back to the binary editor route.
• generic binary content opens in Microsoft Hex Editor when ms-vscode.hexeditor is installed.

How it works

1. VS Code routes *.secnote and *.secbyte to the SecEdit launcher.
2. For an existing encrypted file, SecEdit tries the last successful password kept in process memory. If none is available, or it fails, SecEdit asks for a password.
3. Decryption uses that password directly. Decryption never reads, validates, creates, or changes a passHash file.
4. A zero-byte secure file is opened immediately as a new empty virtual file without asking for a password.
5. Plaintext bytes are exposed through the writable secedit: virtual file system.
6. The inner filename and content classification select the most appropriate editor.
7. When a save requires encryption, SecEdit resolves the encryption password and applies the SecNote/SecByte passHash safety check.
8. Saving re-encrypts the current virtual bytes in memory and atomically replaces the encrypted source.

No plaintext temporary file is intentionally created by SecEdit.

New zero-byte files

A zero-byte *.secnote or *.secbyte file is treated as a new secure file rather than as invalid encrypted content.

• Opening the file never asks for a password.
• Opening the file never reads, creates, or changes a passHash file.
• SecEdit does not attempt to decrypt the empty source.
• The virtual file starts empty and is immediately editable.
• The password is resolved only when the user first saves.
• At first save, a password already cached in process memory is reused. If no password is cached, SecEdit asks for one then.
• The passHash safety check happens immediately before that first encryption.
• The source is encrypted only when the first save succeeds.

Password fingerprint safety

SecEdit preserves the human-error protection used by the SecNote and SecByte CLIs.

The fingerprint is:

SHA-256(password), last 8 hexadecimal characters

The format-specific files are:

~/.secnote.passhash
~/.secbyte.passhash

The passHash exists to prevent accidentally encrypting data with a mistyped password. It is not used to authenticate decryption.

Decryption

When opening an existing encrypted file:

• SecEdit never checks the passHash.
• A cached password is tried directly against the encrypted file.
• If it fails, SecEdit asks for another password.
• Successfully decrypting with a password whose fingerprint differs from the stored passHash does not modify the passHash.

The encrypted file itself determines whether a decryption password is correct.

Encryption and save

Immediately before every encrypted write, SecEdit calculates the fingerprint of the password that will be used:

• If the stored passHash matches, encryption proceeds without prompting.
• If no passHash exists, SecEdit displays the calculated passHash and requires the user to type it exactly before encryption can proceed.
• If the stored passHash differs, SecEdit displays the new passHash and requires the user to type it exactly before encryption can proceed and the stored fingerprint can be changed.
• Cancelling or entering the wrong fingerprint cancels the save before encryption.
• The passHash file is created or replaced only after the encrypted file has been written successfully.
• If updating the passHash fails after encryption, SecEdit attempts to restore the previous encrypted file so the encrypted data and stored fingerprint do not become inconsistent.

This means merely opening or decrypting a file with a different password never changes the user's remembered fingerprint. A fingerprint change happens only as part of an explicitly confirmed encryption.

Change Password

SecEdit: Change Password asks for and confirms the new password, then re-encrypts the active file with it.

If the new password has a different passHash, the normal encryption guard displays that new fingerprint and requires the user to type it before the re-encryption is allowed. After a successful save, the new password becomes the in-memory cached password for subsequently opened files and the matching format-specific passHash is updated.

Editor routing

SecEdit first uses the inner filename, meaning the filename after removing only the final .secnote or .secbyte suffix.

Built-in VS Code previews

• Images: .jpg, .jpe, .jpeg, .png, .bmp, .gif, .ico, .webp, .avif
• Audio: .mp3, .wav, .ogg, .oga
• Video: .mp4, .webm

SVG remains routed to the native text editor by default because it is editable source text.

Optional companion extensions

SecEdit uses these extensions automatically when they are installed:

• ReprEng.csv for .csv, .tsv, .tab, and .psv
• tomoki1207.pdf for .pdf
• ms-vscode.hexeditor for generic binary files

SecEdit discovers contributed custom-editor view types from the installed extension manifest at runtime, with known editor IDs as fallbacks where appropriate.

Text and binary detection

Known text files open in VS Code's native text editor, preserving language detection, syntax highlighting, formatters, and language-server integration.

Unknown extensions are classified using multiple signals:

• binary magic bytes through file-type
• UTF-8 and UTF-16 detection
• NUL-byte ratio
• control-character ratio
• printable-byte ratio
• Shannon entropy as an auxiliary signal

Ambiguous content is sent to a small editor picker instead of being forced into the text editor.

Files up to 1 MiB are inspected in full. Larger files are sampled from the beginning, middle, and end.

Save safety

SecEdit stores a SHA-256 digest of the encrypted source when it is unlocked. Before each save, the current encrypted source is read again and compared with that digest.

If the source changed outside SecEdit, saving does not silently overwrite it. SecEdit offers:

• Reload
• Overwrite
• Cancel

Encrypted writes use a temporary sibling file followed by an atomic rename.

For SecByte files, the original createdAt metadata is preserved and modifiedAt is updated when the virtual file is saved.

Session security

Passwords and decrypted buffers are kept only in process memory while SecEdit is active. SecEdit does not store passwords in settings, environment variables, SecretStorage, the system keychain, workspace state, or global state.

After one password successfully decrypts a file, or after a new zero-byte file is successfully encrypted for the first time, SecEdit keeps that password in memory and tries it automatically for subsequent operations. SecEdit: Lock All Files clears the cached password.

When a session is locked, SecEdit performs best-effort zeroing of its plaintext buffer and drops its password reference. JavaScript strings cannot be reliably zeroed in memory.

A session is automatically locked when its last SecEdit editor tab closes. Commands are also available:

• SecEdit: Change Password
• SecEdit: Lock Current File
• SecEdit: Lock All Files

Important isolation limitation

While a file is unlocked in the native VS Code editor, its plaintext exists inside VS Code's extension-host/editor environment. Language servers and installed extensions that are allowed to observe the virtual document may process that plaintext.

SecEdit protects plaintext at rest on disk. It is not a sandbox against malicious or compromised VS Code extensions.

Development

Requirements:

• Node.js compatible with the installed VS Code extension host
• VS Code 1.120.0 or newer

Install and validate:

npm install
npm test

Compile only:

npm run compile

Production package:

./production-build.sh UltraMegaApps

The development extension entry point is dist/src/extension.js. The production build bundles the runtime into dist/extension.cjs before creating the VSIX.

Architecture

*.secnote / *.secbyte
        |
        v
SecEdit custom-editor launcher
        |
        +---- existing encrypted file ----> cached password or prompt
        |                                      |
        |                                      v
        |                                in-memory decrypt
        |                                (no passHash check)
        |
        +---- zero-byte new file --------> empty virtual document
                                               |
                                               | no password yet
                                               v
                                    secedit: writable FileSystemProvider
                                               |
                                               v
                                          Editor Router

Cmd+S / re-encrypt
  |
  v
resolve encryption password
(cached password or prompt)
  |
  v
passHash encryption guard
  |
  v
in-memory encrypt
  |
  v
atomic replace of encrypted source
  |
  v
update passHash only if needed