Credentials in the encrypted directory

The encrypted directory is yours to open

The server reads and writes only in one directory of a gocryptfs volume: credentials, the dedicated browser profile, the journal, the captures and the downloads. You open and close the volume; the server never mounts or unmounts it, never runs gocryptfs or fusermount3, and never knows its password. While it is closed the server refuses to write, and it has no fallback to an unencrypted place. It accepts the mount only as a fuse.gocryptfs mount of its own user, without the allow_other option.

mcp-server-diwall-browser-setup does it for you, in a terminal of yours, and create writes the operator profile once it has seen the volume mounted. create --temporary makes a volume in memory for a trial, destroyed by close, by the stop of the machine or by the end of your session (the sessions of the sites, the journal and the captures are lost with it); create makes a durable volume; open opens it again; close stops the browser, then unmounts. You type the password at the prompt of gocryptfs; the assistant does not read it. A volume that already exists, copied from another machine or made by Plasma Vault, is taken with create --crypt-dir and --mount-dir: it is not initialised, only opened with your password. Run with no argument, the command reports what your machine allows and the next command.

By hand, with the volume created once (gocryptfs -init, whose master key goes on paper or in a password manager, never in a file of this disk), open it, and, the first time, create the server’s directories:

gocryptfs ~/Vaults/Main.enc ~/Vaults/Main
mkdir -m 700 ~/Vaults/Main/mcp-server-diwall-browser
mkdir -m 700 ~/Vaults/Main/mcp-server-diwall-browser/credentials
mkdir -m 700 ~/Vaults/Main/mcp-server-diwall-browser/browser-profile

To close it, close the dedicated browser first, which keeps files open in its profile, then:

fusermount3 -u ~/Vaults/Main

Never fusermount3 -u -z: a lazy unmount detaches the directory while a process can still write through the old path, which then leads to the unencrypted directory beneath. The open directory must enter no backup: exclude it by file system boundary (rsync --one-file-system) or in your backup tool; the encrypted files can be backed up elsewhere.

One file per site

A credential file holds the user name and the password of one site, in credentials/, in mode 600. Its name is lowercase letters, digits, ., _ and -, at most 64 characters, then .json. Its keys are allowed_origins (required), username and password (at least one of the two), and nothing else:

{
  "allowed_origins": ["https://account.example.invalid"],
  "username": "alice",
  "password": "replace-with-the-real-password"
}

Write it with your editor, never with echo or a shell redirection, which would leave the password in your shell’s history:

vim ~/Vaults/Main/mcp-server-diwall-browser/credentials/account.json
chmod 600 ~/Vaults/Main/mcp-server-diwall-browser/credentials/account.json

The origin is exact. With this file, a page of https://account.example.invalid receives the credential; http://account.example.invalid, https://account.example.invalid:8443 and https://www.account.example.invalid do not (credential_not_bound). A file that lists a wildcard is refused.

What the model does, and what it sees

The model fills a field with a reference, never with the value: {"key": "password"}, or {"key": "password", "name": "account"} when several files are bound to one origin. The server reads the file in its own process at the moment it types, sends the value to the browser over the local debugging connection, and the result says <secret:password>. A field the server deems sensitive (password, card, code) refuses plain text with sensitive_value_refused, so a password cannot pass through the model’s context by mistake.

Credentials kept in an older format, one JSON file per site with host names and no scheme, are not read by the server. A command that you run in your own shell converts a file, or a directory of them, inside its own process and prints no value; it keeps no second factor and overwrites nothing:

cd ~/mcp-server-diwall-browser
.venv/bin/python -m mcp_server_diwall_browser.credential_import \
  --source-dir ~/Vaults/Main/old-credentials

It was tested on files of the test suite in a simulated volume, not on a real gocryptfs volume. Every option, every refusal and the six checks it makes are in section 6 of the operator guide.