task_create opens issues on upstream repo when gh infers laurentenhoor/devclaw from checkout context

[fujiwaranosai850]

Summary

DevClaw can route GitHub tracker operations to the wrong repository when a project is configured against a fork but the local checkout has mixed origin / upstream remotes.

The problem is broader than task_create alone.

In this environment, the devclaw project is registered against yaqub0r/devclaw, but GitHub operations have drifted toward laurentenhoor/devclaw when ambient gh repository inference was allowed to win over project configuration.

The real bug appears to be that GitHub tracker operations do not consistently use the configured project repository as the single source of truth.

Expected behavior

If the DevClaw project entry points to a specific GitHub repository, all GitHub tracker operations should target that configured repository.

For this project, GitHub tracker operations should target:

• yaqub0r/devclaw

and should never drift to:

• laurentenhoor/devclaw

unless that upstream repo is explicitly configured for the project.

Actual behavior

Observed drift has included at least:

• task_create creating an issue on:
  • laurentenhoor/devclaw#529
• downstream tracker paths later failing against upstream instead of the configured fork, for example:
  • HTTP 404: Not Found (https://api.github.com/repos/laurentenhoor/devclaw/labels)
• follow-up regression from an over-broad fix attempt:
  • task_comment failed: unknown flag: --repo

So the failure mode is not just “issue creation went to the wrong repo”.
It is a broader repository-targeting contract problem inside the GitHub provider.

Environment details

Project registry entry:

• workspace devclaw/projects.json shows repoRemote: https://github.com/yaqub0r/devclaw

Local git remotes in /home/sai/git/devclaw:

• origin = https://github.com/yaqub0r/devclaw.git
• upstream = https://github.com/laurentenhoor/devclaw.git

Important clue from the affected environment:

• gh repo view in that checkout resolved to upstream rather than the fork

This means ambient GitHub CLI repo inference in the checkout can prefer upstream even though the DevClaw project registry points at the fork.

Reproduction

1. Register/link a DevClaw project whose configured GitHub target is a fork, for example yaqub0r/devclaw.
2. Use a local checkout whose git remotes include both:
   • origin = fork
   • upstream = canonical upstream
3. Ensure ambient GitHub CLI repo inference resolves to upstream rather than the configured fork.
4. Run GitHub-backed DevClaw tool paths.
5. Observe tracker operations can drift to upstream or fail because they are targeting the wrong repo.

Current understanding of scope

This issue should be treated as a GitHub provider targeting problem, not only a task_create bug.

Potentially affected GitHubProvider behavior includes:

• issue creation
• issue reads / edits / closes / reopens
• label management and transition paths
• issue comments
• PR listing / merge / diff / status helper paths
• reactions
• GraphQL repo lookup paths
• attachment upload paths

The underlying contract should be:

the configured project repo is the source of truth for all GitHub tracker operations

and DevClaw should not rely on ambient checkout-based gh repo inference when project config already specifies the tracker target.

Likely root cause

The GitHub issue/provider path appears to rely too heavily on ambient gh repository inference instead of consistently deriving the target repo from registered project configuration.

There is also an important command-family distinction:

• gh issue, gh pr, gh label, and gh repo can use command-specific explicit repo targeting
• gh api must not be treated exactly the same way as gh issue / gh pr

A blanket “append --repo everywhere” fix is not correct.

Recommended fix

In the GitHub provider layer:

• resolve the target repo from the registered project config
• thread that target explicitly through GitHub provider operations
• do not rely on checkout-context inference once project config specifies the repo
• implement explicit targeting in a command-family-aware way
• ensure gh api paths use a valid explicit-targeting strategy rather than inheriting gh issue / gh pr flag behavior

Acceptance criteria

• the configured project repo is the single source of truth for GitHub tracker routing
• mixed origin / upstream remotes do not cause tracker-routing drift
• task_create creates issues on the configured project repo
• label-management / transition paths use the configured project repo
• representative issue-comment and PR-related provider paths use the configured project repo
• no GitHub provider path relies on ambient checkout repo inference when project config already specifies the repo
• gh api paths are handled with a valid explicit-targeting strategy and do not fail from invalid --repo injection

[fujiwaranosai850]

Testing notes and current status

Pre-implementation reproduction

Confirmed the routing drift described in this issue before the fix.

Evidence from the local DevClaw environment:

• Project config target in devclaw/projects.json:
  • repoRemote = https://github.com/yaqub0r/devclaw
• Ambient GitHub CLI repo resolution from the active checkout/worktree:
  • gh repo view --json nameWithOwner --jq .nameWithOwner
  • result: laurentenhoor/devclaw

This proves the unsafe condition from the issue:

• configured tracker target = yaqub0r/devclaw
• ambient gh target = laurentenhoor/devclaw

Under those conditions, any task_create path that relies on ambient gh inference instead of an explicit repo target can open issues on the wrong repository.

Implementation test

Implemented a fix so provider creation can carry an explicit tracker target derived from project config, and GitHub issue operations use that target rather than ambient checkout inference.

Focused regression test added and passed:

• npx tsx --test lib/providers/provider-targeting.test.ts
• result: 2 tests passed, 0 failed

What the regression test verifies:

1. GitHubProvider.createIssue(...) appends --repo yaqub0r/devclaw when a configured target repo is present.
2. provider repo identity comes from configured target repo without relying on gh repo view in the checkout.

Documentation update

Updated docs/devclaw-self-hosting.md to explicitly call out fork-routing verification for mixed origin/upstream checkouts and to require recording both pre-change and post-change proof for tracker-routing fixes.

Post-implementation live validation status

This part is not yet complete for issue 95.

I attempted to switch the live self-hosted DevClaw install to the issue-95 worktree for end-to-end proof, but I deviated during the live switch and created a duplicate plugin-source collision, then had to recover the live install state.

So the honest current state is:

• pre-implementation failure condition: confirmed
• code fix: implemented
• focused regression test: passing
• docs update: done
• live self-hosted post-fix validation on issue-95 branch: not yet completed

I am leaving this note so the issue has the actual evidence gathered so far, rather than implying the live post-fix proof is already done.

[fujiwaranosai850]

Post-fix live validation

Completed live post-fix validation after switching the installed DevClaw environment to the issue-95 build.

Live install verification

Verified the running self-hosted DevClaw install is now pointed at issue 95:

• openclaw plugins inspect devclaw shows:
  • Source path: ~/git/devclaw.worktrees/issue-95
  • Install path: ~/.openclaw/extensions/devclaw
• verified worktree branch:
  • issue-95
• verified worktree commit:
  • 66940a002e79de655b98460ebc0aece058e077b3

End-to-end tracker-routing proof

Ran a real live validation through the installed task_create tool path.

Validation action:

• created disposable issue via live task_create
• created issue:
  • yaqub0r/devclaw#96
  • URL: https://github.com/yaqub0r/devclaw/issues/96

This is the key proof: the issue was created on yaqub0r/devclaw, the configured project repository, not on laurentenhoor/devclaw.

That demonstrates the post-fix behavior expected by this issue:

• live task_create now routes to the configured tracker repo
• ambient checkout inference did not cause issue creation drift to upstream

Cleanup

Closed the disposable validation issue after verification:

• closed yaqub0r/devclaw#96
• close comment noted it was a disposable validation issue for issue 95 proof

Conclusion

Post-fix validation is now complete for issue 95:

• pre-fix failure condition: confirmed
• fix implemented: yes
• focused regression test: passing
• live self-hosted install switched to issue 95: yes
• end-to-end live task_create routing proof on configured repo: yes

[fujiwaranosai850]

Scope update: issue 95 is not fully resolved yet

New finding from follow-up validation on stable:

• task_create is now correctly routing to the configured project repository
• but task_start still failed with:
  • HTTP 404: Not Found (https://api.github.com/repos/laurentenhoor/devclaw/labels)

This means tracker-routing drift is still present in at least one downstream path after issue creation.

So issue #95 should be treated as only partially fixed so far.

Updated understanding

The real bug scope is broader than just task_create:

• any tool path that performs tracker operations must use the configured project repo target
• no path should fall back to ambient checkout inference when project config already specifies the repo

Practical implication

A complete fix for #95 should include at least:

• task_create routing to configured repo
• task_start / label-management path routing to configured repo
• ideally an integration-style regression test that exercises more than the initial issue-creation call

I’m leaving this note so #95 is not treated as fully done before the remaining routing path is fixed.

[fujiwaranosai850]

Progress update: next patch prepared on issue-95 branch

Added the remaining GitHub repo-target routing fix for the task_start failure surface.

Root cause found

GitHubProvider was forcing --repo for repo, issue, pr, and non-GraphQL api commands, but not for label commands.

That explains the observed failure path during queue/start work:

• label-management calls could still drift to laurentenhoor/devclaw
• resulting in 404s on /labels even though issue creation had already been fixed

Patch

Updated GitHubProvider so label commands also receive the configured repo target.

Regression coverage

Expanded lib/providers/provider-targeting.test.ts to cover:

• issue creation
• issue reads
• issue edits / transition-label path
• label creation
• issue comment API path
• repo-info resolution without ambient gh repo view

Verification

Passed:

• npx tsx --test lib/providers/provider-targeting.test.ts
• npm run build

Branch state

Pushed to:

• issue-95
• head: 9a2919b