Working with Git
Your repository is already there when a workspace opens, and your identity is set up for you. Committing works right away. Pushing back uses credentials you control, because your token is never left sitting on the box.
How your repo gets there
Cloned on first boot
When the workspace is built, RunCode clones the repo you picked into ~/workspace using the git provider you signed in with. Private repos work too, as long as your linked account can see them.
Your identity is pre-set
Your git user.name and user.email are filled in for you, so even your first commit is attributed correctly. There is nothing to set up.
No credentials left on disk
The token used to clone is wiped right after, and origin is reset to the plain HTTPS URL. Your access token never lands in .git/config. That is why pushing asks you to sign in.
Committing
Branch, stage, and commit exactly as you would on your own machine, whether from the integrated terminal or the built-in Source Control panel. Your name and email are already set, so there is no first-time fuss. Everything you commit lives on the workspace disk, which persists across stop and start, so even uncommitted work survives an idle auto-stop.
Pushing your changes
Since the clone token is never stored, origin has
no saved credentials. So your first push asks you to
sign in. Pick whichever option below you prefer. You only set it up once per workspace.
Option A: HTTPS with a token
Keep the HTTPS remote and sign in with a Personal Access Token from your provider.
# HTTPS: authenticate with a Personal Access Token (PAT) from your provider.
# GitHub/GitLab no longer accept your account password here. Use a PAT.
git -C ~/workspace push origin main
# Username: <your-username>
# Password: <paste your PAT>
# optional: let git remember it for this box (stored in plaintext):
git config --global credential.helper storeOption B: SSH key
Generate a key on the box, add the public half to your provider, then switch origin to the SSH URL.
# SSH: create a key on the box and add the PUBLIC key to your git provider.
ssh-keygen -t ed25519 -C "runcode-workspace"
cat ~/.ssh/id_ed25519.pub # copy this into GitHub/GitLab/Bitbucket SSH keys
# point origin at the SSH remote, then push as usual:
git -C ~/workspace remote set-url origin git@github.com:OWNER/REPO.git
git -C ~/workspace push origin mainPrivate repositories
You can create a workspace from any private repository your signed-in account can reach. RunCode uses your linked OAuth connection only at clone time, then drops it. Access stays scoped to your account: anyone you share the workspace with gets that one machine, not your wider git account. See Teams & sharing.
From the browser Source Control panel
The IDE’s built-in Source Control panel shares the same git config as the terminal, so the same rule applies. Staging and committing just work, and the first push asks for the credentials you set up above.
Cloning to your own machine instead? runcode config-ssh lets you git clone straight from a workspace over the
gateway. See Connect over SSH.