How to integrate with GitHub ?

[seepine]

My current desired workflow is:

Use Multica for ticket management, have it complete tasks, and submit code to the main repository via fork & PR.
After I review the code, I can @agent in a Multica issue comment to request revisions.

I tried describing the process in issues, and even created a process skill to add to the agent, but the results weren't ideal. For example, it doesn't fork, doesn't submit PRs, etc. Is there a better way to achieve a similar workflow?

[Bohan-J]

I think you can link your repo in workspace settings page

[seepine]

Hi, i add repo in this, but agent work not good, even though I described the complete workflow in the issue.
I also tried creating a github-workflow skill, but the results weren't great either. I wonder if there are any other suggestions?

[kushalkaushik]

@seepine very curious about your experience! I was actually planning to put my entire KB in GitHub for active memory management purposes. What is not working well for you with the Github repo?

[medoix]

I created a custom github app and wired it up to Multica but it seems quite complicated and then pushes and PRs are from a "Bot" that causes other issues, i am curious how others have Multica gain access to private repo's to pull, commit and raise PR's etc?

[prellr]

I'm building out an entire Ship product to handle all of this. First three phases are posted in PR's but I'll have everything else tested and posted in the next day or two.

[kushalkaushik]

@medoix I’ve done the same thing. I haven’t started testing the workflow yet, but I’m planning to begin this week. I’ll let you know how it goes.

[ADanMan]

Two separate things are being conflated here, and that's most of why the "described the workflow, agent still doesn't fork/PR" experience happens.

The GitHub App (Settings → GitHub) is read-only by design. It links PRs to issues by identifier match, mirrors CI/mergeability onto the issue's PR card, and moves issues to Done on merge — but it never pushes commits, comments, or status checks back to GitHub. The self-host setup docs are explicit about this: the App only ever requests Pull requests / Checks / Commit statuses / Metadata at read-only. There's no write scope to grant here even if you wanted one — connecting the App is not what gives an agent push/fork/PR ability.

Fork, branch, push, and PR creation happen entirely on the machine running your Multica daemon, using that machine's own git/gh credentials — not through Multica's server or the App. When an agent works an issue against a github_repo project resource, the daemon checks the repo out into a dedicated working directory/worktree on that host, but "the AI coding tools a local runtime invokes, those tools' own login credentials, and your local code directories all stay on the connected computer. The Multica server does not execute commands on behalf of local tools." Concretely, if gh/git on that host isn't authenticated with push access, the agent has nothing to push or fork with, regardless of how the issue is worded — this matches "doesn't fork, doesn't submit PRs" exactly.

So the fix is host-side, not prompt-side:

1. On the machine(s) running multica daemon start (or Desktop's embedded daemon), authenticate gh once and wire it into git's credential helper:

   gh auth login          # or: gh auth login --with-token < token.txt
   gh auth setup-git       # makes `git push`/`git fetch` use the gh-stored token

   An SSH deploy key + git remote set-url works too if you'd rather not use gh for the transport.
2. Check it actually reaches the task: gh auth status on that host. The daemon deliberately preserves the real HOME/XDG environment for provider tools like gh, aws, kubectl when running a task, so credentials set up this way are what the agent's gh/git calls inherit — no separate wiring needed inside Multica.
3. Then a skill (or agent instructions) can name the actual commands instead of a vague "submit a PR" ask, e.g.:

   gh repo fork <owner>/<repo> --remote --remote-name fork   # once, if you're forking rather than pushing to origin directly
   git push fork <branch>
   gh pr create --repo <owner>/<repo> --head <your-gh-username>:<branch> --fill

   (gh pr create --head takes <user>:<branch> for exactly this cross-fork case.)

"@agent in a comment to request revisions" doesn't need anything extra beyond the above — it's the same runtime/credentials being reused for a follow-up task, not a separate write path.

One thing worth naming since it's come up in this thread too (@medoix): a Multica-connected GitHub App identity and the daemon-host git identity are unrelated — the commits/PRs an agent produces are attributed to whatever account gh/git on that host is authenticated as, so if you want PRs from a specific bot account rather than your own, that account needs to be the one logged into gh on the daemon host, not something configured on the App side.

If you've already got gh authenticated on the daemon host and it's still not forking/pushing, the next useful piece of information would be whether gh auth status on that specific machine shows an authenticated, push-capable account at the time the task runs — that would tell us if this is a credentials-not-reaching-the-daemon issue or an agent-instruction-following issue, which are different problems.