OpenClaw profiles: separate macOS app instances without mixing state
OpenClaw profiles are a way to keep separate macOS app instances from borrowing each other’s state. In the 2026.8.1-beta.2 release notes, OpenClaw says named app instances isolate state, preferences, Keychain entries, Gateway services, and duplicate-instance ownership, while leaving host-global login and node services alone. That is useful when one Mac runs more than one agent environment and those environments should not quietly merge.
The practical goal is modest: a personal agent, a work agent, and a test environment should have clear boundaries. They may share the same Mac, but they should not share every cached transcript, saved preference, credential reference, or service lifecycle decision just because they happen to run on the same host.
Why OpenClaw profiles matter on a shared Mac
A single Mac is often the convenient place to run an always-on Gateway, test a channel integration, and keep a personal assistant available. The problem appears when a second setup arrives. A work Gateway may need different channels, a separate model login, a different retention policy, or a safer tool configuration. A test instance should be able to fail without changing the live one.
Without instance boundaries, operators tend to create accidental coupling:
- A preference change meant for testing alters the live app.
- A credential lookup uses the wrong saved entry.
- A service restart targets the wrong Gateway.
- Two windows look similar, so a task lands in the wrong environment.
- A second launch competes for ownership of the same local resources.
Those are ordinary operations mistakes, not exotic security failures. They still matter because agents have long-lived state and real tool access. How OpenClaw works is a useful primer on why the Gateway, sessions, channels, and local tools need distinct ownership boundaries.
What the macOS app profile boundary covers
The OpenClaw beta release describes five isolation areas for named macOS app instances. It also states an important limit: host-global login and node services remain shared. A profile is therefore an app-instance boundary, not a claim that one Mac becomes several fully isolated machines.
| Area | What separation is meant to prevent | Operator question |
|---|---|---|
| State | One environment’s local history or runtime state appearing in another | Which agent owns this session and its persisted data? |
| Preferences | Test or work settings silently changing a personal setup | Which instance should this UI setting affect? |
| Keychain | A saved secret reference being selected by the wrong app instance | Which environment is allowed to resolve this credential? |
| Gateway services | Starting, stopping, or repairing the wrong local service | Which named Gateway does this action manage? |
| Duplicate-instance ownership | Two launches fighting over the same app identity | Is this a second intended profile or an accidental duplicate? |
This boundary complements, rather than replaces, named model credentials. AI agent auth profiles focus on selecting and migrating provider logins inside the runtime. macOS app profiles focus on keeping the surrounding app instances from collapsing into one undifferentiated local environment.
OpenClaw profiles and Gateway profiles are related, but different
The names are close enough to create confusion. The official FAQ recommends openclaw --profile <name> for separate Gateway instances, with a unique gateway.port per profile and a per-profile installed Gateway service. The macOS app documentation separately describes saved Gateway profiles for WebChat windows, including their own connection, device-auth scope, transcript cache, offline outbox, and route leases.
The new beta release adds another layer: named macOS app instances with separate local app state, preferences, Keychain handling, Gateway services, and duplicate-instance ownership.
| Layer | Main job | Example decision |
|---|---|---|
| Gateway profile | Run a distinct Gateway configuration | Should work use its own port and service? |
| Saved WebChat Gateway profile | Connect a window to a chosen Gateway securely | Which remote Gateway and device-auth scope does this window use? |
| macOS app profile | Keep native app instances separate on one Mac | Should the work companion share the personal app’s state and Keychain references? |
The layers can work together. They should not be treated as aliases. If the operational requirement is “run two different Gateways,” start with documented Gateway profile and port planning. If the requirement is “keep two native macOS companion setups from leaking into each other’s local app state,” the macOS app profile work is the relevant release feature.
A small-team layout that stays understandable
Most people do not need a profile for every experiment. Extra profiles create their own administration burden. A simple layout usually holds up better:
- Keep
personalfor private channels, private credentials, and the Gateway you use day to day. - Keep
workfor company channels, approved models, and work-specific tool rules. - Keep
testdisposable. Use it to test upgrades, plugins, or channel setup before exposing the live environments. - Give each environment a written owner, purpose, and expected Gateway endpoint.
- Decide deliberately which host-wide services remain shared and document that decision.
This is also a good reason to avoid treating a Mac Mini as a single anonymous agent box. An always-on OpenClaw Mac setup needs service ownership, security updates, and a way to tell a healthy instance from an experiment that was left running last week.
A rollout checklist for OpenClaw profiles
The beta notes establish the feature direction, but production operators should still validate their exact version and deployment path before moving active work. Do not migrate a live personal-and-work setup by intuition.
- Map the current instances. List active Gateways, channels, model credentials, local app windows, services, and ports. Start by identifying existing overlap.
- Write the target boundaries. State which environment owns each channel, Keychain-backed credential reference, Gateway service, and local state directory.
- Create one non-production profile first. Use a test environment with non-production channels and credentials where possible.
- Check service and window identity. Confirm that starting, stopping, and opening the test setup does not change the personal or work instance.
- Test the expected failure paths. Try a wrong credential reference, a restart, a reconnect, and a duplicate launch. The value of an isolation feature is clearest when something goes wrong.
- Review host-global exceptions. The release notes say login and node services remain host-global. Treat those as explicitly shared capabilities, not accidental leftovers.
- Promote only after observing normal work. Verify inbound delivery, a model turn, a local tool action, and a Gateway restart before migrating another environment.
For a broader hardening review, pair this with OpenClaw’s security guide. App-instance isolation narrows one class of mix-up; it does not remove the need for scoped tools, channel policy, network controls, and careful credential handling.
What profiles do not solve
Profiles are not a substitute for operating-system accounts, containers, separate Macs, or a secrets manager. If personal and work data have a compliance requirement that forbids co-residency, use a stronger boundary than two profiles on one laptop.
They also do not turn every host-level capability into a profile-level capability. The beta release explicitly preserves host-global login and node services. That design can be sensible because some macOS integrations belong to the machine, but it means the operator must know where the profile boundary ends.
The right question is not “are profiles enough?” It is “are profiles the right boundary for this specific risk?” They are a good fit for avoiding local state and service confusion between intended OpenClaw setups. They are not the right answer for hard organizational segregation or for an untrusted workload that needs its own host.
FAQ
Are OpenClaw profiles available in a stable release?
The named macOS app-instance isolation described in this article appears in the OpenClaw 2026.8.1-beta.2 release notes. Check the current release channel and official documentation before relying on it for production isolation.
Can I run more than one OpenClaw Gateway?
Yes. The OpenClaw FAQ recommends a named CLI profile per instance, a unique Gateway port, and a per-profile Gateway service. Plan the ports and service labels before starting multiple instances.
Do OpenClaw profiles create separate macOS user accounts?
No. The release notes describe separation for named app instances across local app state, preferences, Keychain, Gateway services, and duplicate-instance ownership. They also say host-global login and node services remain shared. Use separate macOS accounts or hosts when you need stronger isolation.
Should I use a profile for every project?
Usually not. Use profiles where the environments have genuinely different credentials, channels, ownership, lifecycle, or risk. A personal, work, and test split is easier to operate than a large collection of temporary profiles.