safeoutputs MCP: git dubious ownership blocks create_pull_request in agent job (bundle branch pinning); workflow-level safe.directory workarounds ineffective

[consulthys]

Summary

create_pull_request in the safeoutputs MCP server (running inside the agent job via MCP gateway) fails with Git's dubious ownership check when the agent has already created a feature branch and committed locally. The workflow completes with report_incomplete; labels/comments safe outputs may still apply, but no PR is opened and no branch is pushed.

This is the same failure mode reported in #39660 (observed on github/gh-aw itself). Reporting from a consumer org workflow with additional reproduction detail and documented workarounds that do not fix the agent-time failure.

Environment

• github/gh-aw-actions/setup@v0.80.1
• ghcr.io/github/gh-aw-firewall/{agent,api-proxy,squid}:0.27.4
• ghcr.io/github/gh-aw-mcpg:v0.3.26
• engine: copilot (Copilot CLI 1.0.63)
• Pattern: single-repo workflow — agent edits workspace, commits on <feature-branch>, then calls safeoutputs-create_pull_request

Symptom

Every create_pull_request attempt fails during branch pinning (before bundle/patch generation):

Failed to pin branch '<feature-branch>' before bundle generation:
ERR_SYSTEM: fatal: detected dubious ownership in repository at '/home/runner/work/<repo>/<repo>'
To add an exception for this directory, call:

    git config --global --add safe.directory /home/runner/work/<repo>/<repo>

From mcp-logs/safeoutputs.log:

[safeoutputs] Failed to pin branch '<feature-branch>': ERR_SYSTEM: fatal: detected dubious ownership ...

The agent retries multiple times, then calls report_incomplete. The safe_outputs job may succeed afterward but has nothing to push (PR intent was never recorded as a bundle). Branch content remains only on the ephemeral runner workspace.

Root cause (as understood)

1. actions/checkout leaves the workspace owned by the runner user (typically UID 1001 on ubuntu-latest).
2. The safeoutputs MCP server runs in a container (ghcr.io/github/gh-aw-node via MCP gateway) with a different UID.
3. Git 2.35+ rejects operations on repos whose directory owner does not match the current user, unless the path is listed in a trusted safe.directory config.
4. Trusted locations for cross-user access are effectively /etc/gitconfig (system) or configs readable under the container user's home — not the runner's ~/.gitconfig written in pre-steps on the host.
5. The workspace is bind-mounted (${GITHUB_WORKSPACE}:${GITHUB_WORKSPACE}:rw), but repo-local .git/config entries written by host pre-steps are not sufficient for the container's git process (still fails with dubious ownership).

Workarounds attempted (all ineffective for agent-time create_pull_request)

1. pre-agent-steps on the workflow (after checkout, before MCP gateway)

pre-agent-steps:
  - name: Configure git safe.directory for safeoutputs MCP
    run: |
      git config --global --add safe.directory '*'
      if [ -d .git ]; then
        git config --local --add safe.directory '*'
        git config --local --add safe.directory "$(pwd)"
      fi

2. jobs.safe_outputs.pre-steps (same commands after checkout)

Fixes git in the safe_outputs job host context only. That job never receives a bundle because pinning failed in the agent job.

3. Earlier attempt: jobs.agent.pre-steps

Runs before checkout — too early; removed.

None of the above prevent the safeoutputs container from hitting dubious ownership when pinning the branch.

What does work (partially)

• Agent can read/write files, create branches, and commit on the host.
• Other safeoutputs tools (add_labels, add_comment, report_incomplete) work via API paths that do not invoke git in the mounted workspace.
• Only git operations inside the safeoutputs container against the bind-mounted repo fail.

Suggested fixes (platform)

Any of these would unblock consumer workflows that open PRs from agent-authored branches:

1. MCP gateway / safeoutputs container startup: write a system gitconfig (e.g. mount or create /etc/gitconfig) with safe.directory=* or the workspace path before starting the safeoutputs server process.
2. Forward GIT_CONFIG_SYSTEM or GIT_CONFIG_GLOBAL from the agent job environment into the safeoutputs container ( [aw] Linter Miner reported incomplete result #39660 notes these were set on the host but not forwarded).
3. Run safeoutputs git as the same UID as the workspace owner, or chown the workspace in a controlled pre-step visible to the container.
4. Document that workflow-level git config pre-steps cannot fix this, so consumers do not spend cycles on dead-end workarounds.

Impact

Any agentic workflow whose agent commits locally and relies on create_pull_request safe output is blocked on standard GitHub-hosted runners. Manual recovery is not possible after the job ends because branch content is not pushed and bundle transport never succeeds.

Related

• [aw] Linter Miner reported incomplete result #39660 — same error on github/gh-aw Linter Miner workflow (create_pull_request failed 3×; agent documented GIT_CONFIG_GLOBAL / GIT_CONFIG_SYSTEM not forwarded)

[pelikhan]

Update Dockerfile for gh-aw-node

MCP gateway / safeoutputs container startup: write a system gitconfig (e.g. mount or create /etc/gitconfig) with safe.directory=* or the workspace path before starting the safeoutputs server process.

[pelikhan]

fixed in v0.80.3