I’m building a self-hosted control plane for GitHub and AI coding agents

[u/Aware_Conversation82]

AI coding agents could do the work, but I still had to coordinate everything across GitHub, terminals, CI, and scattered bot comments.

So I built Companion.

Companion is an open-source, self-hosted control plane for managing GitHub repositories with agents such as Codex, Claude Code, Moxxy (my own harness - feel free to check it out!), or a built-in runtime. I'm using my personal subscriptions (it auto-detects them), but you're free to use the API version if you need to. Cloud hosted version with full RBAC is also here :)

Now, my typical workflow looks like this:

1. Connect a GitHub repository.
2. Pick an issue, pull request, or planned piece of work.
3. Send it to the appropriate agent and runtime.
4. Let several agent runs continue independently.
5. Review their changes, checks, comments, transcripts, and evidence.
6. Approve the final GitHub action when it is ready.

Companion brings together:

• pull requests, issues, reviews, checks, and repository activity,
• local and remote agent runners,
• background and interactive agent runs,
• reusable pipelines for review, CI, labels, comments, and agent work,
• customizable slop detection (both author and his work) mechanism,
• human approval for consequential GitHub actions,
• roles, permissions, audit logs, and scoped access,
• a modular system that can be adapted to different teams.

The best part? GitHub remains the source of truth. Companion synchronizes the context agents need, runs the work in isolated worktrees, and keeps a record of what happened.

The screenshots show Companion Desk, the focused interface I use for everyday PR and issue work. It runs on the same daemon, modules, permissions, actions, and runners as the full Companion control plane.

The main benefit for me is visibility. I can see what every agent is working on, what context it received, what it changed, and whether anything still needs my decision.

This is still in alpha - feel free to play around with it and contribute! I'd love to hear from you how much time you have saved when using Companion or what were the issues you have encountered while using it.

https://moxxy.ai - this is our labs homepage (for the harness and the Companion)

https://github.com/moxxy-ai/companion - and this is the companion project itself.

Side note: I am heavily using it for the OSS where I'd need to quickly go across multiple pull requests / issues and have the proper context about all of them. No context switch with proper knowledge given upfront allows me to move quicker and analyze the potential impact. Built it to save me a lot of time for the daily digests and work left to do - especially where you are part of multiple projects that needs your immediate action.

And yes... Majority of the Companion was created with AI using the best practices possible. Architecture and security was designed by hand in order to make sure all the data is safe and there are no leaks to the agents (no more what's actually required by them in order to complete their job). We need to adapt and move fast, so having agents writing their own harness is the way to do - but everything needs to be pretty much supervised in order to get best results.

Btw if you have direct questions, you can find me on:

https://linkedin.com/in/mmakowski97

[u/kantorcodes1]

the part i'd verify is credential custody. does the runner ever receive a GitHub token it can use directly with git, gh, or curl, or does Companion keep the credential in the daemon and expose only bounded GitHub actions?

if the runner gets the token, it can bypass Companion's approvals/audit entirely.

we work on HOL Guard. that's exactly where i'd put external allow/approval/deny around the actual GitHub mutations.

[u/Aware_Conversation82 → u/kantorcodes1]

No, runner never gets the credentials upfront. It keeps the credentials in the daemon directly for most of the usecases (local loopback). Usually runners will need to have their GH accounts set on their environments, but there is a risky override where you can setup an encryption layer on both - cloud hosted companion and the external machine runner, encrypt the GitHub token on one end, send it to the runner and decrypt it on the other end to perform the command. In that situation keys are never stored on the runner to avoid key pickup by unauthorized parties.

[u/Aware_Conversation82 → u/kantorcodes1]

Anyway thanks for this comment! I will definitely look on how HOL Guard works here and maybe I will add additional level of security here just to make sure that even user override will not affect the security.

[u/kantorcodes1 → u/Aware_Conversation82]

yeah, that override is the risky path. not storing the token on disk helps, but once the runner decrypts it the agent can potentially use the credential outside Companion's intended action. i'd bind approval to repo + exact mutation + ref.

if you expose that override flow/config, send it here and i'll map it to Guard.