Repository navigation
dispatch-workflow validation fails for workflows in target repo (Side Repo Ops pattern) #31831
Description
This issue has been filed by Claude Code.
Problem
When using the Side Repo Ops pattern with a safe-outputs.dispatch-workflow block that specifies target-repo, gh aw compile fails validation because it looks for the named workflow in the host repo's .github/workflows/ directory instead of the target repo.
Configuration (redacted)
safe-outputs:
dispatch-workflow:
# as per https://github.github.com/gh-aw/patterns/side-repo-ops/
target-repo: my-org/target-repo
workflows:
- build-tools.yaml
target-ref: some-branch
max: 1Compilation error
./my-workflow.md:1:1: error: dispatch-workflow validation failed: dispatch-workflow: workflow 'build-tools.yaml' not found in /path/to/host-repo/.github/workflows
Checked for: build-tools.yaml.md, build-tools.yaml.lock.yml, build-tools.yaml.yml
And without the .yaml extension:
./my-workflow.md:1:1: error: dispatch-workflow validation failed: dispatch-workflow: workflow 'build-tools' not found in /path/to/host-repo/.github/workflows
Checked for: build-tools.md, build-tools.lock.yml, build-tools.yml
Root cause
The validator resolves workflow names against the host repo's local .github/workflows/ directory. When target-repo is a different repository (as required by Side Repo Ops), the workflow file naturally does not exist locally — it lives in the target repo.
Expected behaviour
When dispatch-workflow.target-repo names a repository other than the host repo, the compiler should either:
- Skip local validation — the workflow cannot be verified at compile time without network access to the target repo.
- Accept any workflow name and rely on runtime enforcement (GitHub Actions returns an error at dispatch time if the workflow does not exist).
- Provide an explicit escape hatch such as
validate: falseon thedispatch-workflowblock.
Workaround
None. --approve does not suppress this error (it only bypasses secrets/action approval prompts).
Activity