Load order
Configs are deep-merged. Later sources win.Config schema
<rule> is either:
- A string:
"allow","ask", or"deny"-> applies to all inputs - A pattern map:
{ "<pattern>": "<rule>", ... }-> evaluated in merged rule order; the last matching rule wins
Pattern matching
Rules are evaluated by pattern match, with the last matching rule winning. Put broad rules first and more specific overrides after them.
Examples
1. Deny all bash, ask for writes, auto-allow src/
.symbiotic/symbiotic.json:
2. Allow safe git commands, deny destructive ones
Pattern specificity:git commit *(11 literal chars) beatsgit *(4 literal chars) beats*(0 literal chars).
3. Trust the whole project — allow everything
4. Lock down everything — full review mode
Deep merge behavior
When multiple sources define rules for the same tool, pattern maps are merged (later keys win), and string rules replace entirely. Example:symbiotic.json defines bash rules, .symbiotic/symbiotic.json adds more specific ones:
symbiotic.json:
.symbiotic/symbiotic.json:
“Allow always” persistence
When you choose Allow always at a permission prompt, the approval is saved to the global Symbiotic configuration and takes effect immediately — no restart needed.How patterns are stored
For bash commands, the stored pattern depends on the command structure:
For write/edit, the exact file path is stored.
Shell operator security
Shell-operator handling is enforced by the Bash tool layer. Do not rely on a permission pattern alone to make compound commands safe; review commands containing&&, ||, ;, or | carefully.
Live config reload
The config is re-read from disk on every tool call. You can edit any config file (symbiotic.json, .symbiotic/symbiotic.json, or the file pointed to by SYMBIOTIC_CONFIG) while Symbiotic is running and changes take effect on the next tool execution — no restart required.