The operator profile and the list of sites

Where it lives

~/.config/mcp-server-diwall-browser/profile.json, or under $XDG_CONFIG_HOME when that is set, or the absolute path given in MCP_DIWALL_BROWSER_PROFILE. The file is yours to write, in mode 600, in a directory in mode 700; the server refuses it otherwise and its message gives the chmod to run. It holds no secret. The server reads it again on every call: a change takes effect without a restart.

A key outside the schema is refused. A key that would configure the locked actions, such as payment or deletion, is refused with redlist_in_profile: only the code decides what waits for your confirmation.

The three lists of sites

"allowed_origins": ["https://account.example.invalid", "https://*.shop.example.invalid"],
"confirm_each_change": ["https://account.example.invalid"],
"local_model_origins": []

• allowed_origins: the sites the server reads and acts on, at most 200. Under strict, of any other page the model receives the origin and nothing else.
• confirm_each_change: sites where every click, fill, choice in a list, Enter key and accepted dialog asks for your confirmation, not only payments, deletions and changes of secret.
• local_model_origins: exact origins you want handled by a model running on this machine. The server lists them in status and nothing more, since it has no way to tell where a model runs.

An entry is an origin (scheme, host, port) or a subdomain wildcard. https://*.shop.example.invalid covers every subdomain of shop.example.invalid, one level deep or more, with the same scheme and port, and not shop.example.invalid itself, which needs an entry of its own. A wildcard alone (*), without a scheme, in another place than the first label, or before a name of one level (https://*.test) makes the profile invalid. A wildcard widens reading and acting, never typing: a credential is typed only on the exact origin its file names (Credentials). The server holds no list of public suffixes; a wildcard before one of two levels, such as one that ends in co.uk, is yours to avoid.

The origin policy

The list of sites bounds what the model reads and acts on, never where it navigates. The key origin_policy says what the server does with an origin the list does not hold. You choose it in the profile; the server reads it again at each call, and no tool of the model changes it.

• strict (the default, and what a profile without the key does): the origin is refused, and the model receives the origin and nothing else.
• discovery: the server asks you in a window, once per origin: Refuser (the default answer), Cette séance (read until the server stops, nothing written) or Ajouter à la liste (that exact origin is written in allowed_origins). Five windows at most per server process; a refusal, or no answer in 90 seconds, is not asked again.
• open: every public site is read and acted on, and what the model reads goes to its provider. It is the freest policy and the riskiest, and it is yours to choose. localhost, the names ending in .local and the addresses that are not routable on the Internet stay on the list.

In the three policies, a payment, a deletion and a change of secret keep their confirmation window, and a credential is typed only on the exact origin its file names. To add an origin by hand, put it in allowed_origins. The details are in section 5 of the operator guide.

The rest of the file

• secrets_dir and secrets_crypt_dir: where the encrypted directory is open, and where its encrypted files are kept. With the second, status tells a closed directory from one never created.
• browser: family (chrome, chromium or brave), profile_dir (the --user-data-dir of the dedicated profile) and debug_port (the --remote-debugging-port, 9222 by default).
• limits: at least 250 ms between two actions, 200 actions and 50 pages per server process, by default. An action counts when it starts, once the server is attached; restarting the client starts the counts again.
• declarations: two statements of yours, that the client’s model runs on this machine and that the client never answers a confirmation by itself. The server cannot check them and shows them in status as written. Only with the second may it ask a confirmation through the client, when no window can be shown.

A complete example, which the server accepts as written, is in section 5 of the operator guide.

What a change of the lists leaves behind

Anyone who can write the file can add a site to it, and the server cannot prevent that. It leaves a trace: when one of the three lists, or origin_policy, differs from what the server saw at the previous call, or at its first call from what the last run saved, one line profile_changed goes to the journal in the encrypted directory and status carries the change in server.notices:

"notices": ["profile_changed : allowed_origins +https://shop.example.invalid"]

It is a detection after the fact: it adds no confirmation, and whoever has a shell under your account can also edit the journal. After a session in which a client with a shell was connected, read the journal:

grep profile_changed \
  ~/Vaults/Main/mcp-server-diwall-browser/journal/operations.jsonl