[BUG] Multi-PR Routine completes without doing work due to session branch guard

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?

A Claude Code web Routine whose intended behavior is to create one branch and pull request per work item can be prevented from doing any work by the session-launch designated-branch guard.

Claude Code on the web injects an instruction that designates one working branch and prohibits pushing to another branch without “explicit permission.” That is a reasonable default for a one-session, one-change workflow, but it conflicts with skills and Routines explicitly designed to create multiple independent branches and PRs.

I encountered this on July 13, 2026, in an unattended Routine running with Sonnet 5.

The Routine invoked a skill designed to process multiple bugs across several repositories. Each bug must receive its own worktree, branch, and PR so unrelated fixes are not mixed together.

The session identified the conflict and stopped before creating any branch or PR. Most importantly, the Routine was then shown as completed, despite having performed none of its intended work.

This creates a silent failure mode: an operator may reasonably interpret “completed” as meaning the scheduled workflow succeeded, even though no branches, commits, or pull requests were produced.

The underlying ambiguity is whether deliberately invoking a skill whose documented instructions authorize multiple branches constitutes the operator’s “explicit permission.” In this case, the session treated the session-level branch restriction as overriding the invoked skill’s instructions.

What Should Happen?

When an operator invokes a skill or Routine whose documented behavior explicitly requires separate branches and PRs, Claude Code web should provide a supported way for that workflow to execute unattended without conflicting with the designated-branch guard.

At minimum, the system should do one of the following:

• recognize the invoked workflow’s explicit branch instructions as authorization;
• reliably honor documented multi-branch authorization included in the Routine prompt;
• provide a first-class multi-branch permission for the Routine; or
• stop the run with a clear failed or blocked status explaining how the operator can authorize it.

A run that deliberately performs none of its requested work because of an instruction conflict should not be reported as successfully completed.

Error Messages/Logs

The session explained:

> ... this session's harness instructions say, verbatim:
>
> “DEVELOP all your changes on the designated branch above ... NEVER push to a different branch without explicit permission.”
>
> — one fixed branch per repo...
>
> [SKILL NAME] is explicitly designed to do the opposite: each bug gets its own worktree branched from the repo's default branch [DEFAULT BRANCH NAME] and its own PR, with a hard rule against mixing unrelated fixes into one PR (different conventional-commit scopes, different risk profiles, PR-coherence caps, etc.). Running the routine as designed against three production repos means creating and pushing on the order of 10+ new branches and opening 10+ separate PRs — none of them the designated branch — which is exactly what the “never push to a different branch” instruction forbids.

No conventional error or stack trace was produced.

The Routines UI showed the run as **completed**, despite no branches or pull requests being created.

Steps to Reproduce

1. Define a skill whose documented behavior is to process multiple independent work items.
2. Require the skill to create one worktree, branch, and PR per item rather than combining unrelated changes.
3. On Claude Code web, create an unattended Routine that invokes the skill.
4. Run the Routine against a backlog containing multiple eligible items.
5. Allow the session to identify or enumerate the eligible work.
6. Observe that the session cites the injected designated-branch instruction and concludes that creating the required per-item branches would violate it.
7. Observe that the session stops without creating any branches or PRs.
8. Observe that the Routines UI nevertheless reports the run as completed.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A

Platform

Other

Operating System

Other

Terminal/Shell

Other

Additional Information

Version, Platform, OS, and Terminal Shell are all N/A - this is a bug experienced with Claude Code "on the web"