#Migrating Macs

1 messages · Page 1 of 1 (latest)

idle thornBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

reef glacier
#

@long cosmos Hey buddy

long cosmosBOT
#

That error is coming from OpenClaw trying to create its state dir ($OPENCLAW_STATE_DIR, default ~/.openclaw) and macOS saying “you don’t have permission to write there”.

The weird bit in your paste is: you say your user is primas, but the gateway is trying to create:

/Users/primate/.openclaw

So I strongly suspect you have a user/home mismatch after migration (shortname change, wrong $HOME, or the launchd service is running as a different user than you think).

1) Quick checks (please paste output)

Run these in the same environment you start the gateway from (Terminal, not inside an IDE):

openclaw --version
whoami
echo "$HOME"
ls -ld "$HOME" /Users/primate
# 
ls -ld /Users/primate/.openclaw 2>/dev/null || echo "no /Users/primate/.openclaw yet"
mkdir -p /Users/primate/.openclaw
  • If the mkdir -p /Users/primate/.openclaw fails → the problem is permissions on /Users/primate (or you’re not actually that user).

2) Common fix: fix ownership/permissions (only touch the relevant paths)

If /Users/primate (or the .openclaw folder) is owned by the wrong account, fix it:

sudo chown primate:staff /Users/primate
sudo chmod 700 /Users/primate

sudo mkdir -p /Users/primate/.openclaw
sudo chown -R primate:staff /Users/primate/.openclaw
#

(Adjust primate to whatever whoami says the gateway should run as.)

3) If you migrated from a differently-named account

If your old machine/user was primas and the state dir exists under /Users/primas/.openclaw, you can either:

  • copy it into the new home (/Users/primate/.openclaw), or
  • explicitly set OPENCLAW_STATE_DIR to point at the location you copied (but then you also need to ensure the service/launchd sees that env var).

Docs reference for what lives where: https://docs.openclaw.ai/help/faq#where-does-openclaw-store-its-data

If you paste the outputs from step (1), it’ll be obvious which of the three cases this is.

reef glacier
#

old account was primate. new account is primas

#

It throws the error when I try to use an agent, not before

#

The config had workspace under the primate dirctory hardcoded but I fixed that

long cosmosBOT
#

Yeah — that explains it.

Your logs show OpenClaw is still resolving its home/state dir as /Users/primate, so it tries to create:

/Users/primate/.openclaw

…but you’re now running as primas, so that old home path is either missing or not writable → EACCES.

This is almost always one of these:

  1. you’re still running the old launchd service (installed under the primate environment), or
  2. your shell/service env still has something like HOME=/Users/primate or OPENCLAW_STATE_DIR=/Users/primate/.openclaw, or
  3. your openclaw binary is coming from the old user’s pnpm global dir.

Quick “what’s it using?” checks (paste output)

Run as primas:

#

That’s consistent with the same root cause.

OpenClaw can “look fine” until the first time it actually tries to run an agent, because a bunch of state (sessions, auth profiles, logs, etc.) is initialized lazily under $OPENCLAW_STATE_DIR (default ~/.openclaw). When the agent run starts, it then tries to create the state dir and hits:

EACCES: permission denied, mkdir '/Users/primate/.openclaw'

So the key problem remains: the running gateway process still thinks the state dir/home is /Users/primate, even though you’re now using the primas account.

Can you paste the output of these from the primas account?

openclaw --version
whoami
echo "$HOME"
echo "$OPENCLAW_STATE_DIR"
which openclaw
reef glacier
#

This is on a brand new machine that never had OpenClaw on it. I installed it and then copied over the data as such:

diskutil mount disk2s1
mkdir -p ~/restore-test
rsync -avhE --progress /Volumes/TUKTUK/mbp-migration/clawd ~/
rsync -avhE --progress /Volumes/TUKTUK/mbp-migration/.openclaw ~/
rsync -avhE --progress /Volumes/TUKTUK/mbp-migration/.config ~/ 2>/dev/null || true
rsync -avhE --progress /Volumes/TUKTUK/mbp-migration/.ssh ~/
# 
primas@primas ~ % openclaw --version
whoami
echo "$HOME"
echo "$OPENCLAW_STATE_DIR"
which openclaw
2026.2.21-2
primas
/Users/primas

/Users/primas/Library/pnpm/openclaw
long cosmosBOT
#

Yep — fixing the workspace path is necessary, but this particular error is about the state dir, not the workspace.

EACCES: mkdir '/Users/primate/.openclaw' means the gateway process is still resolving:

  • $OPENCLAW_STATE_DIR (default ~/.openclaw)
    as /Users/primate/.openclaw

So something is still pointing OpenClaw at the old home/user.

1) Confirm what’s still pointing to primate

Run as the new macOS user (primas):

whoami
echo "$HOME"
echo "$OPENCLAW_STATE_DIR"
# 
whoami
echo "$HOME"
echo "$OPENCLAW_STATE_DIR"
which openclaw
openclaw gateway status

In openclaw gateway status, the key bit is whether Config (cli) vs Config (service) differ (that’s the classic “service is running with a different profile/env” issue).

The usual fix

  1. Reinstall the gateway service from the primas environment (this fixes the service/env mismatch):
openclaw gateway install --force

(Ref: https://docs.openclaw.ai/help/faq#why-does-openclaw-gateway-status-show-config-cli-and-config-service-different)

# 
ls -ld /Users/primate /Users/primas
openclaw gateway status

What I’m looking for:

  • If which openclaw points into /Users/primate/... → you’re still using the old user’s global install; reinstall openclaw as primas (pnpm/npx/etc).
  • If openclaw gateway status shows Config (cli) vs Config (service) mismatch → you still have a launchd service installed with the old env; fix is usually:
openclaw gateway install --force

(from the primas environment you want to use)

Once we see those outputs, we can tell whether this is (a) wrong binary, (b) wrong service/env, or (c) a leftover OPENCLAW_STATE_DIR forcing the old path.

# 
which openclaw
openclaw gateway status

In openclaw gateway status, check if Config (cli) and Config (service) differ — that’s the classic “service is running with old env/profile” situation.

2) Most common fix: reinstall the launchd service under primas

This updates the service to use the new user/env (and usually fixes the “why is it using /Users/primate” issue):

openclaw gateway stop
openclaw gateway uninstall
openclaw gateway install --force
openclaw gateway start
reef glacier
#

primas@primas ~ %
primas@primas ~ % openclaw gateway install --force

🦞 OpenClaw 2026.2.21-2 (35a57bc) — Meta wishes they shipped this fast.

Installed LaunchAgent: /Users/primas/Library/LaunchAgents/ai.openclaw.gateway.plist
Logs: /Users/primas/.openclaw/logs/gateway.log
primas@primas ~ % openclaw gateway status

🦞 OpenClaw 2026.2.21-2 (35a57bc) — I don't judge, but your missing API keys are absolutely judging you.

│
â—‡
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-21.log
Command: /opt/homebrew/Cellar/node/25.6.1/bin/node /Users/primas/Library/pnpm/global/5/.pnpm/openclaw@2026.2.21-2_@napi-rs+canvas@0.1.94_@types+express@5.0.6_hono@4.12.1_node-llama-cpp@3.15.1/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 1307, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

long cosmosBOT
#
  1. If which openclaw points into /Users/primate/Library/pnpm/..., reinstall globally as primas so you’re not using the old user’s pnpm install:
pnpm add -g openclaw@latest
pnpm approve-builds -g
  1. If you want to preserve the old state from the old account, copy it over (docs: https://docs.openclaw.ai/help/faq#can-i-migrate-my-setup-to-a-new-machine-mac-mini-without-redoing-onboarding):
  • old: /Users/primate/.openclaw
  • new: /Users/primas/.openclaw

(Then chown -R primas:staff /Users/primas/.openclaw if needed.)

Paste those 5 lines and I’ll tell you exactly which of the above is happening.

reef glacier
# 
primas@primas ~ % pnpm add -g openclaw@latest

 WARN  12 deprecated subdependencies found: are-we-there-yet@2.0.0, are-we-there-yet@3.0.1, gauge@3.0.2, gauge@4.0.4, glob@10.5.0, glob@7.2.3, inflight@1.0.6, node-domexception@1.0.0, npmlog@5.0.1, npmlog@6.0.2, rimraf@3.0.2, tar@6.2.1
Already up to date
Progress: resolved 717, reused 649, downloaded 0, added 0, done
Done in 7.1s using pnpm v10.30.1
primas@primas ~ % pnpm approve-builds -g
There are no packages awaiting approval
long cosmosBOT
#

Good — that confirms the new account (primas) has a working global install and there are no pending native build approvals.

So if you still see mkdir '/Users/primate/.openclaw', it means the running gateway process is still picking up the old home/state dir (usually an old launchd service, or an env var like OPENCLAW_STATE_DIR).

Can you paste the output of these exactly as primas:

whoami
echo "$HOME"
echo "$OPENCLAW_STATE_DIR"
which openclaw
openclaw --version
openclaw gateway status

What to look for / likely fix:

#

If which openclaw still points into /Users/primate/...

Your PATH is still preferring the old user’s pnpm global bin. Fix PATH (or remove the old global install), then retry.

If openclaw gateway status shows service/env mismatch

Reinstall the gateway service under the primas environment:

openclaw gateway stop
openclaw gateway uninstall
openclaw gateway install --force
openclaw gateway start

(That “Config (cli) vs Config (service)” mismatch is a known cause: https://docs.openclaw.ai/help/faq#why-does-openclaw-gateway-status-show-config-cli-and-config-service-different)

Also quick sanity

Make sure the new state dir exists and is writable:

# 
mkdir -p ~/.openclaw
ls -ld ~/.openclaw

Once you paste those outputs, I can tell which branch you’re in (PATH vs launchd service vs OPENCLAW_STATE_DIR lingering).

reef glacier
#

Directory is there, Primas owns all of it and the files are all there.

long cosmosBOT
#

If the directory really exists and is owned by primas, but the gateway still throws:

EACCES: permission denied, mkdir '/Users/primate/.openclaw'

…then one of these is true:

  1. the gateway process is not running as primas (so it can’t write where you think), or
  2. it’s running as primas but can’t traverse/write /Users/primate (common if /Users/primate is still owned/mode’d like a different user), or
  3. you have two state dirs (/Users/primas/.openclaw and /Users/primate/.openclaw) and the running service is still pointed at the old one.

Can you paste these two commands’ output (run as primas)?

ps -ax -o user,pid,command | grep -i openclaw | grep -v grep
openclaw gateway status
#

In particular, openclaw gateway status will usually show a Config (service) line — that tells us exactly which config/state location the running gateway is using.

If it turns out the service is still the old one, the fix is typically to reinstall the macOS service under the new account/env:

openclaw gateway stop
openclaw gateway uninstall
openclaw gateway install --force
openclaw gateway start

(That forces the launchd plist to be regenerated so it stops referencing the old user/home.)

reef glacier
long cosmosBOT
#

If there’s truly no /Users/primate folder at all, then mkdir /Users/primate/.openclaw should fail with ENOENT (no such file or directory), not EACCES.

So the EACCES strongly suggests /Users/primate actually exists (maybe restored by the data import) but is not traversable/writable by the user the gateway is running as.

Two quick “this will reveal it immediately” checks (run as primas):

whoami
echo "$HOME"
dscl . -read /Users/$(whoami) NFSHomeDirectory

ls -ld /Users/primate /Users/primas
ls -ld /Users/primate/.openclaw 2>/dev/null || true

What we’re looking for:

#
  • If NFSHomeDirectory (or $HOME) says /Users/primate even though the username is primas, then OpenClaw is doing the normal thing: ~/.openclaw → /Users/primate/.openclaw. That’s a macOS account/home-dir mismatch (common after migrations/renames).
  • If /Users/primate exists but is owned by some old UID / has restrictive perms, you’ll see it in ls -ld ….

Also: please paste openclaw gateway status — if the service is still installed with some old env/profile, that output usually makes it obvious.

Once I see those outputs I can tell whether the fix is:

  • adjust/fix the macOS home directory mapping (preferred), or
  • reinstall the OpenClaw launchd service under the correct user/env (openclaw gateway uninstall → openclaw gateway install --force), or
  • just fix perms on the leftover /Users/primate directory if that’s the only issue.
reef glacier
#

Ah so there is a primate user on the new machine but that is just the default admin. This is a fresh machine.

#

I installed openclaw after testing Primas, giving it admin and logging in. There were no node or pnpm prereqs before that.

reef glacier
#

@long cosmos amigo

long cosmosBOT
#

EACCES on mkdir '/Users/primate/.openclaw' can happen even if “there is no primate user” because OpenClaw is effectively trying to create /Users/primate (parent doesn’t exist) — and on macOS a normal user can’t create new directories directly under /Users, so it fails with permissions.

So the question becomes: why does the running Gateway think its home/state lives under /Users/primate?

Can you paste the output of these (run as primas in Terminal):

whoami
echo "$HOME"
dscl . -read /Users/$(whoami) NFSHomeDirectory
env | egrep 'OPENCLAW_(STATE_DIR|CONFIG_PATH|PROFILE)' || true
ls -ld /Users /Users/primate /Users/primas
openclaw gateway status

What we’ll learn from that:

#
  • If NFSHomeDirectory (or $HOME) is /Users/primate → macOS thinks your home dir is still the old path.
  • If OPENCLAW_STATE_DIR is set to /Users/primate/... → clear/override it and reinstall the service.
  • If openclaw gateway status shows Config (cli) vs Config (service) mismatch → you’re running an old launchd service; fix is usually reinstalling it under the new env (openclaw gateway uninstall then openclaw gateway install --force).
reef glacier
#

primas@primas ~ % whoami
echo "$HOME"
dscl . -read /Users/$(whoami) NFSHomeDirectory
env | egrep 'OPENCLAW_(STATE_DIR|CONFIG_PATH|PROFILE)' || true
ls -ld /Users /Users/primate /Users/primas
openclaw gateway status
primas
/Users/primas
NFSHomeDirectory: /Users/primas
drwxr-xr-x 6 root admin 192 Jan 27 22:09 /Users
drwxr-x---+ 22 primas staff 704 Feb 21 16:37 /Users/primas
drwxr-x---+ 17 primate staff 544 Feb 21 14:16 /Users/primate

🦞 OpenClaw 2026.2.21-2 (35a57bc) — Say "stop" and I'll stop—say "ship" and we'll both learn a lesson.

│
â—‡
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-21.log
Command: /opt/homebrew/Cellar/node/25.6.1/bin/node /Users/primas/Library/pnpm/global/5/.pnpm/openclaw@2026.2.21-2_@napi-rs+canvas@0.1.94_@types+express@5.0.6_hono@4.12.1_node-llama-cpp@3.15.1/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 2129, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

#

@long cosmos spare some context?

long cosmosBOT
#

That output is super helpful — and it actually shows the smoking gun:

You do have a /Users/primate home folder on the new machine, and it’s owned by primate:

/Users/primate  drwxr-x---+ 17 primate staff ...

So when anything tries to use /Users/primate/.openclaw, primas can’t create folders there → EACCES makes total sense.

The remaining question is: which OpenClaw process is still resolving HOME/state as /Users/primate?
(openclaw gateway status won’t show HOME because it only prints a “safe” subset of env vars.)

1) Verify which process actually owns port 18789

Run: