Multi-Profile Support: Different Policies for Different Projects
Multi-Profile Support: Different Policies for Different Projects
Not all projects are created equal. Your personal side project doesn't need the same safety constraints as your company's production infrastructure. A documentation update doesn't carry the same risk as a database migration script. SafeClaw's multi-profile support lets you define different safety policies for different contexts and switch between them effortlessly.
Why One Policy Isn't Enough
Early versions of SafeClaw had a single global policy. Users configured their rules once, and those rules applied everywhere. It worked — until it didn't.
The feedback was consistent: "SafeClaw is too restrictive for my hobby projects" and "SafeClaw is too permissive for my work projects" — sometimes from the same user. A developer working on a personal blog and a banking API needs fundamentally different guardrails.
A single policy forces a compromise. Either you set it tight enough for your most sensitive project and deal with constant escalations on everything else, or you set it loose enough for daily work and accept the risk on critical projects. Neither option is good.
How Profiles Work
A profile in SafeClaw is a named collection of policy rules, workspace boundaries, rate limits, budget constraints, and notification preferences. You can define as many profiles as you need.
``yaml
profiles:
personal:
workspace: "~/personal"
policy: permissive
rate_limits: relaxed
budget: null
work:
workspace: "~/work"
policy: standard
rate_limits: default
budget: 25.00/day
production:
workspace: "~/work/prod-*"
policy: strict
rate_limits: aggressive
budget: 5.00/session
require_approval: [delete, deploy, migrate]
`
Automatic Profile Selection
You don't have to manually switch profiles. SafeClaw automatically selects the appropriate profile based on the workspace directory. When you open a terminal in
~/personal/my-blog, the personal profile activates. When you navigate to ~/work/prod-api, the production profile takes over.
Profile selection uses a longest-prefix match, so more specific paths override more general ones. If you have both a
~/work profile and a ~/work/prod- profile, the production profile wins for any project matching the prod- pattern.
You can also override the automatic selection with a command-line flag or an environment variable, useful for CI/CD environments where the workspace path might not match your local structure.
Profile Inheritance
Profiles can inherit from other profiles, reducing duplication. A common pattern is a base profile with sensible defaults and specialized profiles that override specific settings:
`yaml
profiles:
base:
policy: standard
rate_limits: default
notifications: [slack]
sensitive:
inherits: base
policy: strict
require_approval: [write, delete, execute]
notifications: [slack, email]
``
Inheritance is single-level to keep behavior predictable. We considered multi-level inheritance and decided that the complexity wasn't worth it — deep inheritance chains make it hard to reason about which rules are actually in effect.
Per-Profile Analytics
The SafeClaw dashboard shows analytics broken down by profile. You can see which profiles trigger the most escalations, which have the highest risk scores, and where your agents are spending the most budget. This data helps you tune profiles over time — tightening rules where you see risky behavior and relaxing them where escalations are consistently approved.
Team Profiles
For teams, profiles can be shared via version control. Include your SafeClaw configuration in your repository, and every team member gets the same safety policies for that project. This is especially valuable for onboarding — new developers inherit the team's carefully tuned safety configuration on their first clone.
Profile configurations are documented in detail in our documentation. The profile system implementation is fully open source on GitHub.
The Right Tool for the Right Job
Multi-profile support reflects a simple truth: context matters. The same action that's perfectly safe in one project might be dangerous in another. SafeClaw's profiles let you express that context as configuration, so the right rules are always in effect without any manual switching.