[BUG] Workflow tool's scriptPath resume handle becomes unreadable after a mid-session working-directory change

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When using the Workflow tool's scriptPath resume mechanism, a mid-session working-directory
change causes the resume call to fail with a misleading error, even though the script file still
exists on disk at the exact path the tool itself returned earlier.

Specifically: Workflow with an inline script returns a scriptPath for later resume/iteration,
persisted under a path derived from the working directory at the time of the original call (e.g.
.../projects/-...-repo-a/.../workflows/scripts/my-workflow-wf_xxxx.js). If the session's cwd
later changes to a different repo (e.g. via a shell command run from that other repo), calling
Workflow({scriptPath: <that same path>}) fails — the tool treats the path as unreadable/invalid,
rather than resolving it or explaining that the rejection is due to a cwd mismatch.

What Should Happen?

Expected: The resume handle stays valid across a cwd change within the same session, or the error
clearly states why it's rejecting the path (cwd mismatch) instead of implying the path itself is
invalid or was never returned by the tool.

Error Messages/Logs

Error: scriptPath must be a script path this tool returned, or a file you can already read (the
working directory or a directory you have added): /Users/.../projects/-...-repo-a/<session>/workflows/scripts/my-workflow-wf_xxxx.js

Steps to Reproduce

1. While cwd is repo-A, call the Workflow tool with an inline script parameter (any valid

workflow script). Note the scriptPath the tool returns in its result — it will look like
.../projects/-...-repo-A/.../workflows/scripts/<name>-<runId>.js.

1. Change the session's working directory to repo-B — e.g. run a Bash command whose working

directory is a different repo (in my case, a git -C repo-B worktree remove ... command, which
the harness then treats as shifting cwd to repo-B).

1. Call the Workflow tool again, this time with {scriptPath: <the path returned in step 1>}

(optionally with resumeFromRunId set to the original run's ID to attempt a cached resume).

1. Observe the error above. The file at that path still exists and is readable directly (e.g. via

cat or the Read tool) — only the Workflow tool's own scriptPath acceptance check rejects it.

Note: the failure is specifically tied to the cwd having changed since the original call, not to
anything about the script content or the resumeFromRunId value — resubmitting the same script
inline via the script parameter (not scriptPath) from the new cwd succeeds immediately.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.288 (Claude Code)

Platform

Google Vertex AI

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Possibly related: anthropics/claude-code#80249 — same error surface ("scriptPath rejected"), but
a different trigger (session boundary/compaction rather than a plain mid-session cwd change).
Flagging in case the two share a root cause: scriptPath validation may be tied to a path derived
from cwd/project-directory context that can shift under more than one circumstance. That issue is
closed/stale, so filing this as a separate, more narrowly-reproducible report rather than
commenting there.

Note: the script name visible in the error path/filename reflects whichever workflow script
happened to be running at the time (taken from the script's own meta.name field) — it is
incidental, not the cause. The failure occurs purely on the Workflow tool's scriptPath validation,
before the script's own content is ever read or executed.