#Exec failed to run because of .openclaw folder is a symlink.

13 messages · Page 1 of 1 (latest)

random loom
#

I run openclaw on a RPi. To save the sd card from the writing, I symlink ~/.openclaw to a dir on my ssd /mnt/ssd/openclaw. Now all my execs are refusing to run and says "Refusing to traverse symlink in exec approvals path" even if the command to be run isn't related to that folder at all.
Anyone else using symlink? Any possible workaround or solution?

fair sparrowBOT
exotic urchinBOT
#

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

fair sparrowBOT
hoary yarrowBOT
#

Yep, that one is very likely the symlink itself, not your command.

Refusing to traverse symlink in exec approvals path means OpenClaw is rejecting a symlink anywhere in the approvals file path, and ~/.openclaw -> /mnt/ssd/openclaw trips that. This was tightened as a security hardening change around 2026.2.26.

So, short answer: symlinking ~/.openclaw is not a good workaround for exec anymore.

Best options:

  1. Use a real directory via OPENCLAW_HOME
    Example:

    export OPENCLAW_HOME=/mnt/ssd/openclaw-home

    Then restart the gateway/node. If you run it as a service, set that env in the service, not just your shell.

  2. Use a bind mount instead of a symlink
    A bind mount looks like a normal directory to the symlink checks.

#
  1. Move the actual service user's home/state onto the SSD
    Same idea, just no symlink in the path.

Also, separate but related: approval-backed exec now also rejects a symlinked cwd/workspace. So if you later see approval requires canonical cwd, check that too.

Docs:

Can you paste openclaw --version? I can tell you if you're on the exact release where this behavior landed.

random loom
#

OPENCLAW_HOME, OPENCLAW_STATE_DIR, OPENCLAW_CONFIG_PATH which one should I use? What are their differences?

hoary yarrowBOT
#

For this specific symlink/exec-approvals problem, use OPENCLAW_HOME.

Quick difference:

  • OPENCLAW_HOME
    Changes the base “home” OpenClaw uses for internal ~ paths.
    This affects things like:

    • ~/.openclaw/exec-approvals.json
    • agent dirs
    • sessions
    • credentials

  • OPENCLAW_STATE_DIR
    Changes the mutable state dir, default ~/.openclaw
    Good for logs, sessions, caches, etc.
    But it does not fix your exec-approvals issue by itself, because exec approvals are still resolved from OPENCLAW_HOME.

#
  • OPENCLAW_CONFIG_PATH
    Changes only the config file path.
    Useful if you want config somewhere custom, but it won’t fix this issue alone either.

Recommendation

If your goal is “put OpenClaw stuff on the SSD and avoid the symlink”, simplest is:

export OPENCLAW_HOME=/mnt/ssd/openclaw-home

Then restart OpenClaw.

If you run it as a service, set that env in the service definition, not just your shell.

In one sentence

random loom
#

The original OPENCLAW_HOME is set to ~/.openclaw, right?

hoary yarrowBOT
#

Nope, that’s the important distinction 🙂

By default:

  • OPENCLAW_HOME is not ~/.openclaw
  • it is effectively your home directory ($HOME)
  • then the default state dir is ~/.openclaw

So roughly:

  • OPENCLAW_HOME default → /home/pi
  • OPENCLAW_STATE_DIR default → /home/pi/.openclaw

That’s why exec approvals still care about the “home” path logic.

So if you set:

# 
OPENCLAW_HOME=/mnt/ssd/openclaw-home

then the default state dir becomes:

/mnt/ssd/openclaw-home/.openclaw

If you want, you can think of it like this:

  • OPENCLAW_HOME = base folder
  • OPENCLAW_STATE_DIR = where .openclaw lives
  • OPENCLAW_CONFIG_PATH = exact config file

Docs: https://docs.openclaw.ai/help/environment