OpenClaw macOS app profiles: separate work and personal agent state
OpenClaw macOS app profiles let you run a work agent and a personal agent on the same Mac without treating them as one shared environment. A named profile separates its state directory, app preferences, Keychain services, duplicate-instance lock, and CLI-managed Gateway service. That is a better boundary than keeping everything in one default profile and hoping the right agent stays in the right context.
The feature is especially useful when one Mac handles distinct accounts, projects, or risk levels. It does not turn a profile into a security sandbox, and it does not remove the need for tool approvals. It does give the operator a concrete ownership boundary for the local app and Gateway.
Contents
- What OpenClaw macOS app profiles isolate
- When a named profile is the right choice
- Start a profile deliberately
- What still stays host-global
- A practical profile layout
- FAQ
What OpenClaw macOS app profiles isolate
A named profile starts the macOS app with the same profile name used by the OpenClaw CLI. The current macOS app documentation says a profile keeps its own state under ~/.openclaw-<name>, app defaults, Keychain services, duplicate-instance lock, and Gateway LaunchAgent. The associated service uses the profile name, such as ai.openclaw.work.
This matters because agent context is not only a chat transcript. It can include configured providers, Gateway state, local preferences, credentials stored through the app, and the service that keeps the Gateway alive. Combining those into one default profile makes it easier to point a work task at a personal setup by accident.
| Boundary | Default profile | Named macOS app profile |
|---|---|---|
| State directory | ~/.openclaw | ~/.openclaw-<name> |
| Gateway LaunchAgent | ai.openclaw.gateway | ai.openclaw.<name> |
| App defaults and Keychain service | Shared default context | Profile-specific context |
| Duplicate app instance | Default app lock | Separate lock for the named profile |
| Port selection | Normal config or environment behavior | Stable profile-derived port unless configuration overrides it |
The release notes for OpenClaw v2026.8.1-beta.2 describe the same boundary: named app instances isolate state, preferences, Keychain, Gateway services, and duplicate-instance ownership. The release explicitly keeps host-global login and node services outside that profile boundary.
When a named profile is the right choice
Use a named profile when the separation has a real operating purpose. Good examples include:
- A work agent that has business providers, repositories, and a work-specific Gateway.
- A personal agent that should not inherit work-side preferences or stored app credentials.
- A dedicated automation profile with a narrower set of tools and approvals.
- A test profile used to trial a new model or integration before changing a relied-on default setup.
This is a useful complement to the broader self-hosted OpenClaw operating model. A profile decides which local app and Gateway context owns the work. Tool policy still decides what that agent may do.
Do not create profiles merely to label every chat. If the state, credentials, service ownership, and risk level are the same, a new profile adds another process to maintain without providing a meaningful boundary. Use a separate conversation or agent first. Create a profile when the operating context itself must remain separate.
Start a profile deliberately
macOS app profiles are described in the v2026.8.1-beta.2 release notes. If you use the stable channel, first verify that your installed version includes this feature; do not assume the command below is available in an older stable build.
The upstream macOS app README shows the direct launch pattern:
OPENCLAW_PROFILE=work /Applications/OpenClaw.app/Contents/MacOS/OpenClawUse a short, descriptive name. Profile names accept lowercase letters, numbers, underscores, and hyphens; they must start with a letter or number. The upstream docs reserve default, gateway, mac, and node for LaunchAgent identities, so do not use those names for a custom profile.
Before launching it, decide what the profile is for and document that choice. A small inventory is enough:
- Owner and purpose. For example,
workhandles company research and coding;personalhandles home automations. - Provider and account boundary. Connect only the identities intended for that profile.
- Gateway ownership. Check that the profile’s LaunchAgent name and local port do not conflict with another managed service.
- Tool policy. Keep the automation profile’s tools and approvals appropriate to its job.
- Update path. Named profiles intentionally avoid app relocation, Sparkle updates, and post-update service repair. Update the installed app through the normal default-profile workflow instead.
The OpenClaw macOS app guide is the source of truth for local versus remote Gateway mode and the app’s permission flow. For a default local Gateway, the macOS Gateway guide documents the normal LaunchAgent lifecycle and OPENCLAW_PROFILE selection.
What still stays host-global
A profile is an isolation boundary inside the OpenClaw app model. It is not a second macOS user account and it does not claim the whole machine.
OpenClaw’s release notes say that host-global login and node services remain untouched while a named app profile is active. In practical terms, do not assume that a profile replaces macOS account separation, filesystem permissions, or the security review required for a tool that can affect the host.
This distinction is important for browser and computer-use workflows. The OpenClaw browser security guide explains why an agent’s browser access needs its own explicit boundaries. A profile can keep Gateway and app state separate; it does not make a sensitive website action safe by itself.
OWASP makes the same broader point for agent systems: grant only the tools required for the task, scope permissions per tool, and require explicit authorization for sensitive operations. Treat a profile as one layer in that design, not the final control.
A practical profile layout
A two-profile setup is often enough for one Mac:
| Profile | Intended use | Keep out of it |
|---|---|---|
work | Company repositories, work providers, internal automations | Personal accounts, experimental tools, personal browser data |
personal | Home tasks, personal research, private automations | Work credentials, company repositories, broad admin tools |
For an automation-heavy Mac, a third lab profile can make sense. Keep it disposable: use it for a new provider, a custom skill, or a beta feature. If it becomes useful, promote the configuration deliberately rather than letting experiments accumulate inside the work profile.
The same principle applies to mobile and remote access. A paired OpenClaw mobile app can connect to a Gateway, but the Gateway profile should still be clear about which context it represents. Naming the profile after its ownership boundary makes support, recovery, and review less error-prone.
FAQ
What are OpenClaw macOS app profiles?
OpenClaw macOS app profiles are named app instances that isolate their OpenClaw state directory, app preferences, Keychain services, duplicate-instance lock, and CLI-managed Gateway service. They use the same profile naming model as the OpenClaw CLI.
How do I launch an OpenClaw macOS app profile?
Launch the app with OPENCLAW_PROFILE=<name> set, for example OPENCLAW_PROFILE=work /Applications/OpenClaw.app/Contents/MacOS/OpenClaw. Use a valid non-reserved profile name and decide its account, Gateway, and tool-policy boundaries before connecting services.
Do macOS app profiles isolate the whole computer?
No. They isolate OpenClaw app and Gateway context. They do not create a separate macOS user account, replace filesystem permissions, or make high-impact tool actions safe without policy and approval controls.
Should every OpenClaw agent use a separate macOS profile?
No. Use a separate profile when state, credentials, Gateway ownership, or risk level need to remain separate. For ordinary task separation inside the same operating context, separate sessions, agents, and tool policies are usually simpler.
The useful boundary is ownership
OpenClaw macOS app profiles are most valuable when they make ownership obvious. A work Gateway should not quietly become the place where personal credentials and experimental tools accumulate. A lab environment should not inherit the authority of a production workflow.
Start with two profiles only when the boundary changes what the agent can access or how the service is operated. Then keep the decision visible in the profile name, provider setup, tool policy, and Gateway service. That is more durable than trying to reconstruct intent from a mixed default profile later.
Sources: