cross-repo create-pull-request can succeed and then fail with allowed-repos ERR_VALIDATION

[brase]

Summary

In a cross-repository workflow, create-pull-request can successfully create the pull request and continue with follow-up actions, but then later fail with an ERR_VALIDATION allowed-repos error and mark the run as failed.

This produces a false-negative result:

• the branch push succeeds
• the PR is created successfully
• labels are applied
• the protected-files fallback review/comment path runs
• but the same handler later fails and reports the operation as unsuccessful

Expected behavior

If the pull request is successfully created, the handler should either:

• complete successfully, or
• treat a later bookkeeping/notification problem as a warning

It should not report PR creation failure after the PR already exists.

Actual behavior

The same create-pull-request handler:

1. pushes the changes
2. creates the pull request
3. applies labels
4. creates the protected-files comment/review fallback
5. then fails with:

ERR_VALIDATION: Repository '<TARGET_REPO>' is not in the allowed-repos list. Allowed: <CONTROL_REPO>

After that it may also create a fallback issue, and then still report:

Failed to create both pull request and fallback issue

Redacted log excerpt

This excerpt is from a private repository setup, so repository names and object numbers are redacted. The key point is that the PR is already created before the allowed-repos validation failure occurs.

Created pull request #<PR_NUMBER>
Added labels to pull request: ["automation","project-assist","enhancement"]
Creating REQUEST_CHANGES review for PR #<PR_NUMBER> due to protected files
Cannot submit REQUEST_CHANGES on own PR #<PR_NUMBER>. Retrying with COMMENT.
Created COMMENT review fallback for PR #<PR_NUMBER>
Failed to create pull request: ERR_VALIDATION: Repository '<TARGET_REPO>' is not in the allowed-repos list. Allowed: <CONTROL_REPO>
Falling back to creating an issue instead
Created fallback issue #<ISSUE_NUMBER>
Failed to create both pull request and fallback issue. PR error: ERR_VALIDATION: Repository '<TARGET_REPO>' is not in the allowed-repos list. Allowed: <CONTROL_REPO>. Issue error: ERR_VALIDATION: Repository '<TARGET_REPO>' is not in the allowed-repos list. Allowed: <CONTROL_REPO>
Message 1 (create_pull_request) failed

Why this looks like a bug

The same handler has already successfully performed cross-repo actions against the target repository before the validation error is raised.

That suggests a later code path is re-validating repository routing with the wrong repo context or the wrong allowed-repos set. In the failing state, the validation error reports only the control repository as allowed, even though the create-pull-request and create-issue handlers are configured with the target repo and an explicit allowlist.

Workflow shape

This is a MultiRepoOps-style setup:

• a control repository dispatches a worker workflow
• the worker checks out exactly one target repository into the workspace
• safe outputs then create/update issues or PRs in that checked-out target repository

Relevant worker configuration:

checkout:
  repository: ${{ github.event.inputs.target_repo }}
  path: ./target-repo
  github-token: ${{ secrets.GH_AW_CROSS_REPO_PAT }}
  fetch-depth: 0
  fetch: ["refs/pulls/open/*"]
  current: true

safe-outputs:
  github-token: ${{ secrets.GH_AW_CROSS_REPO_PAT }}

  create-pull-request:
    github-token: ${{ secrets.GH_AW_CROSS_REPO_PAT }}
    target-repo: ${{ github.event.inputs.target_repo }}
    allowed-repos:
      - <TARGET_REPO_A>
      - <TARGET_REPO_B>
      - <TARGET_REPO_C>
      - <TARGET_REPO_D>
      - <TARGET_REPO_E>
      - <TARGET_REPO_F>
      - <CONTROL_REPO>
    title-prefix: "[project-assist] "
    labels: [automation, project-assist]
    draft: true
    max: 4

  push-to-pull-request-branch:
    github-token: ${{ secrets.GH_AW_CROSS_REPO_PAT }}
    target: "*"
    target-repo: ${{ github.event.inputs.target_repo }}
    allowed-repos:
      - <TARGET_REPO_A>
      - <TARGET_REPO_B>
      - <TARGET_REPO_C>
      - <TARGET_REPO_D>
      - <TARGET_REPO_E>
      - <TARGET_REPO_F>
      - <CONTROL_REPO>
    required-title-prefix: "[project-assist] "
    max: 4

  create-issue:
    target-repo: ${{ github.event.inputs.target_repo }}
    allowed-repos:
      - <TARGET_REPO_A>
      - <TARGET_REPO_B>
      - <TARGET_REPO_C>
      - <TARGET_REPO_D>
      - <TARGET_REPO_E>
      - <TARGET_REPO_F>
      - <CONTROL_REPO>

The workflow prompt also explicitly instructs the agent to include the target repo in PR-related tool calls:

- For every `create_pull_request` call, include `repo: "${{ github.event.inputs.target_repo }}"`.
- For every `push_to_pull_request_branch` call, include `repo: "${{ github.event.inputs.target_repo }}"`.

Impact

This makes workflow conclusions unreliable for cross-repo PR automation:

• operators see red runs even though the useful output already exists
• downstream workflows gated on success may not run
• fallback issues add noise even though PR creation already succeeded

Request

Could you check whether a later step inside create-pull-request is re-validating repository routing using the wrong allowed-repos context in cross-repo runs?

At minimum, if the PR was already created successfully, a later validation/bookkeeping failure should not convert the entire operation into a terminal PR-creation failure.