LabsFeatures
What the checkout model buys, where shredding stops working, how sessions expire, and why a command exists whose whole purpose is to let you walk away from the vault entirely.
The Vault Lifecycle
Six commands cover almost everything you will ever do.
encino initCreate the vault
Calibrates Argon2id to about a second on your hardware and records those parameters, so the cost is right for the machine and the vault stays openable later. Prints a 24-word recovery code once. Refuses if a vault already exists there, so a mistyped repeat cannot destroy your keys.
encino addImport documents
Walks folders recursively, never descending into .encino. Names are relative to the folder you named, the same rule as cp -r. Originals are shredded only if they were already inside the vault folder — anything from elsewhere is copied and left alone.
encino unlockStart a session
Derives the key once and hands it to a background agent that holds it in memory locked out of swap. Writes nothing to disk and decrypts nothing — authentication and exposure are deliberately separate concerns.
encino openCheck one document out
Decrypts into the vault folder, staging plaintext inside .encino and moving it into place only once it decrypts and matches the recorded digest — so a failure never leaves a partial document that looks whole.
encino closeCheck it back in
Re-encrypts and shreds the plaintext. A document that comes back byte-for-byte unchanged keeps its existing ciphertext; an edited one is re-encrypted under a fresh key and its old ciphertext removed. Empty folders are tidied away.
encino lockEnd the session
Closes everything still open, stops the agent, and forgets the key — in that order, since re-encrypting needs it. If anything cannot be closed, the session is deliberately left open rather than stranding plaintext with no key to re-seal it.
Behaviour Worth Knowing
Most of these are decisions that only look obvious after the alternative has gone wrong once.
One document at a time
The checkout model is the reason encino exists rather than a folder-level encryption tool. A design that decrypts the whole folder leaks plaintext revisions into a sync provider's version history, where the user cannot delete them. Here, only what you asked for is ever readable, and the vault folder tells you exactly what that is: anything visible in the root is, by definition, currently decrypted.
Unchanged documents cost nothing to close
A document that comes back byte-for-byte identical keeps its existing ciphertext. Reading a bank statement and closing it again performs no re-encryption at all. One that was edited is re-encrypted under a fresh content key and its old ciphertext is removed, so no superseded version lingers in the blob store.
Shredding, and its honest limits
Plaintext is overwritten when it is destroyed, but shredding cannot guarantee erasure on an SSD — wear levelling means overwriting a logical block does not reliably erase the physical one. Run encino on a BitLocker-encrypted volume; volume encryption is the real mitigation. On a network share, shredding is close to meaningless, because overwrites go to the server where snapshots and backups keep the originals.
add refuses to surprise you
By default originals are only shredded if they were already inside the vault folder. That is deliberate and it matters more than it sounds: encino add . run from the wrong directory would otherwise shred every file in that directory, with nothing to alert you until you went looking for something. --move opts into destroying outside originals, lists what it is about to destroy, and asks first.
Case collisions are refused at import
A name differing from an existing document only by case is rejected, so a vault written on Linux stays openable on Windows and macOS. The check happens at add time rather than at open time, when it would be far too late.
Sessions expire, and clean up after themselves
--timer sets how long a session lasts: default 30 minutes, maximum twelve hours, because a session outliving the working day defeats the point of having one. On expiry the agent re-encrypts anything still open before forgetting the key. open --timer requires a running session and says so plainly rather than implying a timer that will never fire.
passwd never touches a document
Because the passphrase wraps the master key rather than encrypting documents directly, changing it rewrites one small file however many documents the vault holds. The recovery code is unaffected and still works.
verify authenticates the whole vault
Confirms every blob is present, its key unwraps, it decrypts, and its digest matches what the index recorded. It also reports stored blobs no document refers to. It reads everything, so it takes time proportional to total size, and exits 1 if anything is wrong.
A vault is never a one-way door
encino export <dest> decrypts the whole vault into a directory, preserving folder structure, and leaves the vault untouched. It asks for confirmation, because the result is plain readable files that encino no longer protects, and the destination must be empty or not yet exist.
This command exists for one reason: so that committing documents to encino is never a decision you cannot reverse. It is worth running once on a test vault, before you trust it with anything, to prove to yourself that you can always walk away with your documents.
encino export C:\Temp\vault-check
Decrypt all 148 documents to C:\Temp\vault-check? [y/N]
Vaults on a Network Share
Works on a UNC path or a mapped drive, and a vault is portable between them — Z:\Docs and \\server\share\Docs reach the same vault interchangeably.
One session may hold a vault at a time
Error: \\server\share\Financial is in use by
process 8412 on DESKTOP-ABC
That refusal is doing real work. Sessions replace the index wholesale, and each document's content key lives inside its index entry — so two concurrent writers would mean the later save destroying the earlier one's key, leaving an undecryptable blob and a shredded original. The document would be gone.
The lock is a held file handle, not a marker file, so a crash or a dropped connection releases it immediately. A leftover .encino/work.lock is not a stale lock and needs no cleaning up.
Shredding is close to meaningless on a share
Overwrites go to the server, where snapshots and backups keep the originals. Nothing encino does on the client side can reach them.
Encryption at rest still works exactly as it does locally — the blobs on the share are the same opaque blobs. It is only the destruction of plaintext that the network breaks, which matters most for the add and close paths.
encino writes no logs
The session agent runs detached with its output discarded, so when it dies unexpectedly there is nothing to look at. Diagnostics are opt-in via ENCINO_AGENT_DEBUG, and nothing is written when off — no file is created and no panic hook is installed.
$env:ENCINO_AGENT_DEBUG = "1"
encino unlock
# reproduce the problem, then:
Get-Content "$env:LOCALAPPDATA\encino\agent.log"
Remove-Item Env:\ENCINO_AGENT_DEBUG
The log records no key material, no passphrase, no document names and no vault contents, and lives outside the vault so it cannot become metadata attached to your encrypted folder.
It is off by default because when a session ran is itself a record of when you worked with your documents — the sort of thing the encrypted index exists to hide. Turn it on while investigating, then turn it off.