Skip to content
ACT

Profiles & config

The CLI reads ~/.config/act/config.toml at startup. It holds host defaults and named profiles — per-component bundles of grants and metadata you activate with --profile <name>.

Layout

Section titled “Layout”
~/.config/act/config.toml
listen = "[::1]:3000"
log-level = "info"


[audit]
enabled = true            # the audit trail is on by default; this is how you turn it off
detail = "rollup"         # "rollup" (default) or "full"


# ── Runtime-wide policy baseline ────────────────────────────────────
[policy]
default = "ask"                   # deny | allowlist | open | ask
"wasi:sockets" = "deny"           # shorthand: a bare mode string
"db:*" = "deny"                   # `*`-suffix patterns match by prefix


[policy."wasi:filesystem"]        # structured: mode + provider-defined constraints
mode = "allowlist"
allow = [{ path = "/data/**", mode = "rw" }]
deny  = [{ path = "**/.ssh/**", mode = "ro" }]


[policy."wasi:http"]
mode = "allowlist"
allow = [{ host = "api.example.com", scheme = "https", methods = ["GET", "POST"] }]


# ── Per-component profiles ──────────────────────────────────────────
[profile.sqlite-dev]
[profile.sqlite-dev.policy."wasi:filesystem"]
mode = "allowlist"
allow = [
  { path = "/Users/me/dev/**", mode = "rw" },
  { path = "/dev/urandom", mode = "ro" },
]


[profile.sqlite-prod]
[profile.sqlite-prod.policy."wasi:filesystem"]
mode = "allowlist"
allow = [
  { path = "/var/lib/acme/**", mode = "rw" },
  { path = "/dev/urandom", mode = "ro" },
]

Keys under [policy] are capability ids — wasi:filesystem, wasi:http, wasi:sockets, act:credentials, or a semantic class a component declares — or *-suffix patterns. Each value is either a shorthand mode string or a { mode, allow, deny } table, with the same provider-defined constraint shapes as the CLI’s --grant. See Policy & sandbox.

Priority

Section titled “Priority”

Grants merge, later winning:

  global [policy]  <  profile [policy]  <  CLI --grant / --allow / --deny

Within a layer, an id resolves by exact id > longest *-prefix > default. An unset default inherits from the layer below; absent from every layer, it is ask.

Using a profile

Section titled “Using a profile”
Terminal window
act run actpkg.dev/library/sqlite --mcp --profile sqlite-dev \
  --session-args '{"database_path": "/Users/me/dev/app.sqlite"}'

A profile can carry policy and metadata. It cannot carry session args — those are a per-connection concern and stay on the command line (or come from the credential store). A profile’s metadata merges with any -m / --metadata-json on the CLI, per key, CLI winning.

Overriding the config path

Section titled “Overriding the config path”
Terminal window
act run <component> --mcp --config ./my-config.toml

Useful in CI or per-project setups.

What belongs here

Section titled “What belongs here”

Good fits: capability grants you’d otherwise retype, long allow-lists, network baselines for a team, host paths, non-secret per-deployment metadata.

Not here: secrets. Credentials live in the credential store — put them there with act secret set, or let act login prompt for what a component declares it needs, and the component receives them through session args rather than through config. Component versions don’t belong here either; pin the OCI tag at the call site.

Example: MCP client setup

Section titled “Example: MCP client setup”
{
  "mcpServers": {
    "sqlite-dev": {
      "command": "npx",
      "args": ["@actcore/act", "run", "actpkg.dev/library/sqlite", "--mcp",
               "--profile", "sqlite-dev",
               "--session-args", "{\"database_path\":\"/Users/me/dev/app.sqlite\"}"]
    }
  }
}

Your MCP client never needs to know about grants — they live in the profile.