Publishing to GitHub

Publish to GitHub… turns a project folder inside a VM into a GitHub repository in one step. exe commits what is not committed yet, creates the repository on your account, private by default, and pushes. Publish the same folder again later and the new commits go to the same repository.

• For you, what was built in a VM lands on GitHub without your setting up git, a remote or a key in the VM.
• For the VM, nothing is handed over: no GitHub credentials ever enter it. Your sign-in stays on this machine, out of reach of whatever runs in the VM, an agent included.
• For an agent, publishing is one tool or one HTTP call that the daemon carries out. A plain git push inside a VM always fails, because that is the point.

Publishing to the web gives a running service an address; this chapter puts the code itself on GitHub.

Sign in to GitHub once

exe signs in with GitHub's device flow, through an OAuth app of your own:

1. At github.com, open Settings → Developer settings → OAuth Apps and create an app. Enable Device Flow. The flow needs no callback URL and no client secret.
2. Open Windows → Configuration → GitHub, put the app's client ID there (github.client_id) and Save.
3. Click Sign in with GitHub…. github.com/login/device opens in a new tab, and a code appears in the window.
4. Enter the code at GitHub. The window then says who you are signed in as.

Once the client ID is saved, the Publish dialog offers the same sign-in at its top. Sign Out, clicked twice, removes the token from this machine.

Publish a folder

1. In the Virtual Machines window, right-click a running VM and choose Publish to GitHub….
2. Pick the Project folder in the VM. The dialog lists the folders in the VM's home.
3. Check the Repository name, which starts as the folder's name.
4. Leave Private repository ticked, or clear it for a public one.
5. Click Publish.

The dialog lists each step as it happens and ends with a link to the repository. The Newsfeed notes the publish too, with a link to the commit.

What Publish does

The daemon does the work, over SSH into the VM:

1. Installs git in the VM if it is missing. The install uses apt, so it expects a Debian VM.
2. Makes the folder a git repository if it is not one yet, on a branch named main.
3. Commits any uncommitted work. If git has no identity for the folder yet, exe sets one for that repository only: your GitHub account, under its noreply address.
4. Creates the repository on your account, or uses the one that already has that name. Private repository counts only when the repository is created.
5. Points the folder's origin at the repository and pushes the current branch.

It stops early for a folder that sits inside a larger git repository (publish that repository's own folder instead) and for a detached HEAD (check out a branch first).

Publishing again goes through the same steps, so it commits what changed and pushes the new commits to the same repository.

Let an agent publish

• The Chat agent. Tell it to "push to github" and it uses the daemon's github_push tool on the project folder.
• Any other agent. POST /v1/vms/{name}/publish with {"path":"/home/dev/app","repo":"app","private":true} does what the dialog does. It streams its steps and ends with the repository's address and the pushed commit. Say "private":true: left out, a new repository is public.

Either may leave the repository name out. exe then reuses the folder's origin when it points at your account, so publishing again updates the same repository, and otherwise takes the folder's name. If origin points at another account, it stops and asks for a name.

You sign in first, as above: without a sign-in the publish fails and says where to sign in. The Agent Skill Guide tells agents to publish only when you ask, since the call can create a repository on your account.

Why the VM never holds your token

The point of the design: no GitHub credentials ever enter the VM.

• The sign-in token lives only on this machine, in ~/.exe/github.json.
• The push travels through a proxy that exists just for that one operation and answers only for that one repository.
• The VM's git talks to that proxy without ever holding a token, on disk or in memory. The daemon adds the token on its own side.