Device Settings & ConfirmationsNEW

Since v2.2.0 a device's owner can manage a Sophon Node from the Dashboard: its name, the folders the agent may use, and its confirmations, the dialog on the device that asks before sensitive actions. Changes apply live on the node, without a restart, or at its next connect if it is offline.

Before v2.2.0 the folders and the confirmation list could only be set by editing the node's config.json on the machine. That file still works, and it is still the baseline: a section you never manage from the Dashboard keeps following it.

The Settings tabCopy Anchor Link

Devices → (device) → Settings opens with three panels, which refresh every 10 seconds. Permission scopes, Activity history, Token management and Send command follow them, as before.

Until a device has reported its settings, the Confirmations and Folders panels show one of these instead of their controls:

"Settings are not available for this device" means you can open the device but not manage it, for example as an admin of another workspace.

When two people save at once, the second save is refused with "Changed elsewhere. Review and save again." and the panel reloads the current settings. A save in one panel does not clear unsaved changes in the other.

Who can change whatCopy Anchor Link

Loosening a device is the owner's decision. Admins can tighten.

Loosening is turning confirmations off or lengthening an off period, removing an action from the ask list, adding a folder, choosing the default folders, and handing a section back to the device. Tightening is the opposite: turning confirmations back on or shortening an off period, adding an action, removing a folder, turning file access off.

On the Personal tier the single user owns every device. Since v2.2.0 an admin who is not a device's owner can no longer loosen its settings.

Set on this device, or managed from SophonCopy Anchor Link

Each section, folders and confirmations, starts as Set on this device: the node's config.json decides. The owner's first save makes it Managed from Sophon, and that first save starts from what the device reported, so its existing folders and ask list are kept rather than reset. Hand back to the device (owner only) returns a section to config.json.

Sophon never edits config.json for these settings. The node keeps what it applied in ~/.sophon-node/managed-settings.json, written only by the running node, and applies it again at the next start before it connects.

Under each section a line says where the change stands:

• "Applied on the device"
• "Sending to the device…" (online)
• "Waiting for the device. Applies when it reconnects." (offline)
• "The device refused this change: it is locked."
• "Set on this device"

"Last changed by" names you, "the device's owner", "an administrator", or "Sophon (host policy)" when the host kill switch switched the device back on.

ConfirmationsCopy Anchor Link

Some actions ask the person at the computer first. A dialog on the device, titled with the action (for example "Sophon Node: Run a shell command"), shows its full detail and refuses the action if nobody answers within 15 seconds. This dialog is separate from Sophon's approval cards: an agent action can need both. How the dialog behaves is described in Gates, Limits & Audit.

The ask listCopy Anchor Link

By default the dialog asks before shell commands (system.execute) and the canvas (canvas.present). Managed from Sophon, the list is edited in the Confirmations panel:

Shell commands and the canvas cannot be removed from a managed list. To stop asking before them, turn confirmations off for a while. Actions the device listed that are not in this catalog show as "Set on this device" and are kept on save. Removing an action is owner-only and asks first; adding one is open to the owner and admins.

Turning confirmations offCopy Anchor Link

The switch "Ask on the device before these actions" asks before it turns confirmations off, names the actions nobody at the computer will be asked before, reminds you that anyone at the computer can run sophon-node lock, and offers five durations:

Only the device's owner can turn confirmations off, and not while the device is locked or the host forbids it. The switch shows the reason when you cannot.

While confirmations are off:

• Every action on the ask list runs without the dialog, and the node audits it as skipped.consent.
• The devices list and grid show a Confirmations off chip. Its tooltip is the end time ("Until 6:00 PM" or "Until turned back on").
• The panel shows a banner saying until when, for example "Confirmations are off until 6:00 PM (in 3 h 12 m).", with Turn back on, which the owner or an admin can use. The banner warns when the device's clock is more than 2 minutes off Sophon's.
• Only the owner can send the device a command that is on its ask list. Anyone else, and a command with no requesting user such as an automation, is refused (409 confirmations_off) until the device itself reports confirmations on again.
• Sophon's own approval cards still apply to agent actions, as your approval settings say.

The off period ends at the earlier of the end Sophon sent and the chosen duration counted on the computer's own clock from when the node first saw it, so neither a restart nor a slow clock lengthens it. Within 15 seconds of the end the node asks again and audits consent.rearmed.

The computer shows a notification whenever Sophon loosens its settings, such as "Sophon can act on this computer without asking until 6:00 PM. To stop this, run: sophon-node lock", and "Sophon will ask again before acting on this computer." when confirmations come back on. The node builds that text from fixed sentences, counts and local times only, never from a name, path or text sent by Sophon. On macOS the notification may not appear; this is unverified there.

Under the switch the panel shows whether the device applied the change, "Last changed by" with when, Hand back to the device (owner only), and the device's last 20 confirmation outcomes.

FoldersCopy Anchor Link

The Folders panel shows whether the folders are set on the device or managed from Sophon, the folder list with a remove button per folder, an add field, Use defaults (Desktop, Documents, Downloads) and Turn off file access.

• Folders apply only when the device holds the filesystem.access scope. The panel warns when it does not.
• Adding folders, using the defaults and handing the list back to the device are owner-only and ask first. An admin can remove folders or turn file access off once the list is managed from Sophon.
• A folder the Gateway refuses is marked on its row. The node checks each folder again, after following every link, leaves out a folder it refuses, and the panel lists it with the reason.

Folders managed from Sophon pass more checks than folders in config.json:

On Linux, /var/home counts as a folder that holds homes, like /home. Ostree-based desktops such as Fedora Silverblue, Kinoite and Bazzite link /home to /var/home, so folders there apply as on any other computer, whether typed /home/…, /var/home/… or ~/…. /var/home itself and the rest of /var stay refused. Linuxbrew's /home/linuxbrew counts as a system folder on Linux.

A node whose home folder sits inside a system folder, such as a Windows service running as LocalSystem or a node running as root on Linux, refuses every folder managed from Sophon. Set its folders in its own config.json instead. See Running as a Service.

The checks that apply to every file path, wherever the folders come from, are in File Access.

The local lockCopy Anchor Link

A person at the computer can stop Sophon from loosening anything there:

sophon-node lock      # Sophon cannot turn confirmations off or widen folder access
sophon-node unlock    # remove the lock
sophon-node status    # the confirmations, the lock and its file, and the settings managed from Sophon

While the device is locked:

• Confirmations are on, whatever Sophon says.
• The dialog always asks before shell commands, opening apps, opening the canvas and creating or changing files, and before every action that was on the ask list when the device was locked, even if the list is shortened later.
• Folders managed from Sophon can only narrow the folders set in config.json.
• The Dashboard shows "Locked on this device" and keeps the switch on. A change that would loosen is reported as refused, and Sophon refuses to turn confirmations off (409 confirmations_locked).

The lock is the file ~/.sophon-node/local-policy.json. The running node reads it before each action that could ask, so lock and unlock apply to the next command without a restart. A lock file that cannot be read counts as locked. Deleting it by hand unlocks: the lock is a tool for the person at the computer, not tamper protection. pair and unpair keep the lock. After unlock, an off period set from Sophon that has not ended applies again.

A node installed as a Windows service under LocalSystem reads another profile's folder (C:\Windows\System32\config\systemprofile\.sophon-node). sophon-node lock prints the path it wrote and, on Windows, this caveat, so lock the profile the service uses.

Forgetting the managed settingsCopy Anchor Link

sophon-node settings reset

forgets the settings managed from Sophon on this computer. A running node applies config.json again within 15 seconds. A Gateway 2.2.0 or later sends its settings again at the next connect.

Use it after downgrading the Gateway below 2.2.0. A managed node connected to an older Gateway keeps the folders and ask list it last applied, with confirmations on, until you run settings reset on it.

Host kill switchCopy Anchor Link

An operator can forbid turning confirmations off on the whole Gateway:

{ "Sophon": { "Nodes": { "AllowConfirmationsOff": false } } }

Sophon:Nodes:AllowConfirmationsOff defaults to true. When it is false, turning confirmations off is refused (403 confirmations_off_disabled), every device reads as on, and devices that are off are switched back on and sent the change. A change in <dataDir>/config/appsettings.user.json applies without a restart. The environment variable SOPHON__Nodes__AllowConfirmationsOff is read only at start, and that file overrides it, so an environment change needs a restart.

The hardened dialogCopy Anchor Link

v2.2.0 also changes how the confirmation dialog itself behaves, on every device, managed or not:

• The default answer is No. The Windows dialog's default button is No, and on Linux the default is Reject, so pressing Enter refuses.
• No PowerShell injection on Windows. The dialog and notify.show notifications run a fixed PowerShell script and receive their text on standard input, so quotes, $(…) and backticks in a command are shown as typed and never run.
• Stop closes the dialog. A Stop sent while the dialog is open closes it, on macOS too, and the command does not run. When the agent stops waiting for a node command (its timeout), the Gateway cancels the command on a connected device, and an open dialog closes.
• Input is refused while a dialog is open. Mouse and keyboard commands are refused (rejected.consent_pending), so an agent cannot click its own Approve. Remote view clicks and typing are refused too, so Remote view cannot answer the dialog.
• Full detail. The dialog shows the command line, app arguments, file paths and content, and the whole typed text, up to 4,000 characters. Control, bidi-override and zero-width characters are shown as \uXXXX escapes.

REST routesCopy Anchor Link

Anyone else gets 404. A login that has not chosen a workspace yet gets 403 tenant_selection_pending. A save body names only the sections it changes:

{ "baseRevision": 7,
  "fileSystem": { "roots": ["C:\\Users\\ann\\Documents"] },
  "confirmations": { "enabled": false, "offFor": "8h", "commands": ["system.execute", "canvas.present"] } }

offFor is one of 1h, 8h, 24h, 7d or indefinite. "roots": null means the node's default folders, "roots": [] turns file access off, and { "managed": false } hands a section back to the device. A save that loses a race answers 409 stale_revision.

Every save and rename writes an audit row (nodes.settings.update with the old and new values, nodes.rename) in the same transaction, so a failed audit fails the save. Refused attempts are audited as nodes.settings.refused.

LimitsCopy Anchor Link

• Without the lock, the owner's login decides. Anyone holding the owner's login, or a compromised Gateway, can turn a device's confirmations off. Owner-only loosening, the bounded durations, the audit, the chip, the notification on the device and the kill switch make that visible; sophon-node lock prevents it.
• input.control amounts to control of the desktop. The scope is granted by default, and an agent that can type can open a terminal and run sophon-node unlock. The ask list covers mouse and keyboard actions only if you add them.
• The owner rule is enforced by the Gateway. The node cannot tell who sent a command.
• Some devices cannot show the dialog. A headless Linux machine or a Windows service in session 0 refuses every action on the list; turning confirmations off is the remedy there.
• Not in v2.2.0: editing node settings from Mobile.

Where to go nextCopy Anchor Link

• Gates, Limits & Audit — the on-device prompt and every audit outcome
• File Access — the path checks that apply to every file command
• Install & Pair a Node — the sophon-node CLI
• Permissions & Scopes — what a device is allowed to do at all