fumi lets web pages trigger local executables. That is an intentionally dangerous capability, so the design is conservative: the bridge between the browser and your shell exposes the smallest possible surface, and almost every restriction is enforced on the host side where an attacker cannot reach.

• A compromised web page running an action. The page cannot forge calls with arbitrary paths, read files outside scripts/, or pass shell-interpreted arguments.
• A malicious or buggy action trying to escape. It still cannot resolve paths outside scripts/, follow symlinks out, or execute non-script files.
• An unrelated extension or process trying to talk to fumi-host. The manifest's allowed_origins pins exactly the extension IDs baked into the build; Chrome refuses to broker connections from anyone else.

• The host machine already being compromised. If an attacker can write to ~/.config/fumi/scripts/, they can run anything you can run. fumi assumes the filesystem is trustworthy.
• Scripts you write yourself. fumi will happily execute rm -rf ~ if you put it in a script. Treat every script as code you own and audit.
• Payload-level attacks. If your script parses the payload carelessly (shell interpolation, SQL concatenation, arbitrary code execution), fumi cannot help. Treat payloads as untrusted input.
• A compromised Chrome profile or extension signing key. If the attacker controls the pinned extension ID, they can call the host. Protect your Chrome Web Store developer account accordingly.

fumi-host speaks JSON-RPC 2.0 over Chrome's Native Messaging stdio transport. The entire API is three methods:

• actions/list — returns parsed frontmatter from actions/*.js. Read-only.
• scripts/run — executes a file in scripts/ with a JSON payload on stdin.
• host/version — returns the host's build version string (the same value as fumi-host --version). Read-only metadata; the extension uses it to warn when its version and the host's drift apart.

There is no file read, no file write, no directory list, no environment introspection, no "eval this code", and no way to pass a path or command outside of a scripts/ entry. Adding one would require a new method, a host rebuild, and a fumi setup --force.

Every scripts/run call runs the candidate path through these checks, in order. Any failure aborts before spawn.

Symlinks are rejected rather than followed. A compromised action cannot plant a symlink to /bin/sh inside scripts/ to escape.

• No shell. Scripts are exec'd directly; there is no sh -c, so shell metacharacters in payloads are inert.
• No argv injection. The host never passes user-controlled arguments. argv[0] is the script path and nothing else.
• Stdin-only payload. The JSON payload is written to the child's stdin. A script that never reads stdin cannot be influenced by the payload at all.
• Environment scrubbed. All FUMI_* variables from the parent environment are dropped; only FUMI_STORE is re-set. Callers cannot smuggle state via environment variables.
• Working directory pinned. Cwd is the directory containing the script, not wherever the extension happened to start.

These exist to keep a single bad script from hanging or flooding the host:

These are hard limits enforced in the host. A runaway script is killed; a flood of output is truncated and the call rejects.

The Native Messaging manifest's allowed_origins list contains exactly one ID, compiled into the fumi binary at build time from extensionID in cmd/fumi/constants.go. Both the Chrome Web Store build and unpacked dev builds (via the dev-key injection in scripts/build-dev.sh) resolve to that same ID, so a single pin covers both.

Any other extension that tries to open a port to com.tkrmt.fumi is rejected by Chrome before fumi-host is even spawned. Changing the pinned ID requires rebuilding fumi and re-running fumi setup --force.

• The store at ~/.config/fumi/ is created with mode 0700; only your user can read it.
• config.toml is 0600.
• fumi uninstall removes the manifest but leaves the store, so removing fumi does not delete your scripts. Delete ~/.config/fumi/ manually if that is what you want.

Error codes are returned in JSON-RPC error.code and are stable across versions. Protocol-level codes (PROTO_*, INTERNAL) match JSON-RPC 2.0 conventions; domain codes are in the -33xxx range.