Does the open hands agent canvas self hosted version plan on getting github integrated like the cloud version?

Hey @clean-postman-32056, yes we support integration with github! Go to the “automate” tab and click on the github automations here. This process is supported, but @millions-afternoon-47582 is revamping it right now, so if you have any feedback on things that were trickier than they should’ve been please tell us!

I'd love to hear what you are working on and where you've been having issues with onboarding @clean-postman-32056 . The initial setup is something I've been focused on a good bit recently so any feedback would be great to hear. I have open calendar time available with this link calendar.app.google/… or you can message me hear on slack as well. Thanks in advance!

@limited-student-10747 I see what appears to be github repo monitoring in the automate section. I was looking for a way to link a github repo so i can choose a repo on a project for it to use to push or pull from. The cloud version makes it easy to add a repo for projects to use.

Ah, got it, on the front page we have “open workspace” which allows you to import a directory that is already on your machine and the agent will be able to easily push/pull from it given the proper credentials (e.g. the github mcp or an authenticated github CLI). If the directory isn’t on your disk yet, you can ask an agent to clone it for you.

Personally, I have a “repos” directory which is the workspace. It has, well, repos, many of them. The agent works there. • it has a github token in secrets, it can always pull / push on github too • it has an authenticated

gh

cli, too I feel like this allows me to not micromanage each repo, and helps the agent work with multiple repos naturally.

Did it again, you can see the opencode in the chatbox selected by me and what the agent flipped to.

When I was first introduced to OpenHands I could have sworn this was implemented already. Turns out it was, before the canvas migration. For full context my agent dug through the git history to work out what happened. In a nutshell what it found is: Back when this repo still held the Python

app_server

and the original frontend, there was a full repo picker: - A git router exposing paginated repository, branch and installation search - A per-provider integrations tree (GitHub, GitLab, Bitbucket, Bitbucket DC, Azure DevOps) - A

Settings -> Git

page where you pasted a PAT - Provider/repo/branch dropdowns on the home screen Self-hosted users pasted a token and picked a repo. No cloud account involved and it wasn't cloud-gated either: the git endpoints were registered for every deployment, without a flag hiding them from self-hosted users. Then at some point it was deleted completely by

cb9138ca

("chore: clear repository for Agent Canvas migration (#15397)"). --- Interestingly it still exists in the frontend too:

GitService.searchGitRepositories

and

retrieveUserGitRepositories

are right there, except both are now guarded with

if (isInvalidProvider(provider) || !isCloudActive()) return EMPTY_REPOSITORY_PAGE;

and otherwise delegate to the Cloud app-server. So the client half survived the migration and got gated to cloud use only. The server half that answers those calls isn't in any public OpenHands repo anymore. I wasn't around when the migration happened, so I'd guess dropping the integrations layer wasn't really much of a choice. The agent-server is a runtime, so I imagine it was never meant to hold that kind of thing. Still, the end result feels off to me. Something that used to work if you self-hosted now only works if you're on the hosted product. When I started using the new agent canvas I was also looking for a quick way to start on a project and that's exactly what the old picker gave you. On a local backend today there's nothing that provides that quick first experience. On the "just tell the agent to clone it" argument: I don't think that's as straightforward as it sounds. It only works if you already know the agent can do it, if you already have an opinion about where your projects should be stored and if you have GitHub MCP and/or

gh

PAT set up already. That's a lot to assume for a new user. For most people the UI is how you find out what a tool is capable of. IMO if something only happens when you know to ask for it, it feels more like hidden functionality than a feature.

Those are good points! I'm pretty sure it wasn’t exactly intended as a miss, but I do feel that the direction we’re heading to, need to be something like… how do I put this, to use the agent more and leave for hardcoded UI what needs to be hardcoded in the UI. Some things need to be. This one, idk. If it needs to be in UI, what if the UI would give a tip above the prompt box, for a new conversation without a workspace? e.g. “_you can choose a workspace with an existing clone or ask the agent to clone a repo_” Related, I wonder. If you don’t have an opinion where projects should be stored and you’re on the local backend, are you OK with the application placing it somewhere on disk?

how do I put this, to use the agent more and leave for hardcoded UI what needs to be hardcoded in the UI.

I get what you mean.

Some things need to be. This one, idk. If it needs to be in UI, what if the UI would give a tip above the prompt box, for a new conversation without a workspace?

Yeah, something like that could solve it too. I think it's mostly a discoverability issue actually, if you think about it. Users just need some way to learn that it is supported like that, in a "what you prompt is what you get" kinda fashion. Whether you communicate that through a dedicated UI component or a hint is up for debate.

Related, I wonder. If you don’t have an opinion where projects should be stored and you’re on the local backend, are you OK with the application placing it somewhere on disk?

Hmm I haven't considered that question yet because I'm using docker and therefore I don't really care where it's placed by default 😅 What about the OS' standard app directory (like

~/.local/share/OpenHands

for example on Linux)?