Skip to content

[Bug]: exec workdir with leading ~ falls back and still executes command #94434

Description

@renaudcerrato

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

exec does not expand a leading ~ in workdir, then falls back to another directory and still executes the command, causing relative commands to run from the wrong location.

Steps to reproduce

  1. Start OpenClaw 2026.6.8.

  2. Trigger an agent/tool call equivalent to:

    {
      "workdir": "~/<workspace>/skills/example",
      "command": "./scripts/run.py"
    }
  3. Observe that workdir is treated literally, reported unavailable, and the command is run from a fallback directory.

Expected behavior

For an explicit invalid workdir, OpenClaw should either:

  • expand leading ~ / ~/ consistently with other user-facing path inputs, or
  • fail the tool call without executing the command from a different directory.

Actual behavior

The tool emits a warning and still executes the command from the fallback directory:

Warning: workdir "~/<workspace>/skills/example" is unavailable; using "<fallback-cwd>".

zsh:1: no such file or directory: ./scripts/run.py

Command not found

OpenClaw version

2026.6.8

Operating system

Ubuntu 24.04.4 LTS

Install method

npm global, running as a systemd user service

Model

Observed after an Ollama cloud model emitted the tool call, but the behavior is in the exec tool runtime after the structured tool arguments are produced.

Provider / routing chain

OpenClaw -> configured model provider -> OpenClaw exec tool

Additional provider/model setup details

Provider likely not relevant. The issue is reproducible from the structured exec arguments once a model emits workdir with a leading ~.

Logs, screenshots, and evidence

Redacted example:

Warning: workdir "~/<workspace>/skills/example" is unavailable; using "<fallback-cwd>".

zsh:1: no such file or directory: ./scripts/run.py

Command not found

Local package comparison showed the same resolveWorkdir() behavior in several recent published versions, so this does not appear to be a newly introduced regression in 2026.6.8.

Impact and severity

Affected: Agent runs that use structured exec.workdir with a leading ~.

Severity: Medium. It can break scheduled or isolated runs and make the real failure non-obvious.

Frequency: Intermittent; depends on whether the model chooses workdir: "~..." instead of cd ~/... inside the shell command.

Consequence: Relative commands fail from the fallback directory, and recovery depends on the model noticing and correcting the path.

Additional information

This does not require full shell expansion. Full shell expansion in structured fields may be undesirable.

The safer request is either:

  • support only leading home expansion for path-like structured fields, or
  • fail fast when an explicit workdir is invalid instead of executing from a fallback directory.

The main concern is the silent fallback: an invalid explicit workdir can cause commands to execute from a different directory than intended.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:linked-pr-openClawSweeper found an open linked pull request for this issue.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:otherThis issue has meaningful maintainer-visible impact outside the owned taxonomy.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions