// workspaces

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.

terminal
# 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 store

Option B: SSH key

Generate a key on the box, add the public half to your provider, then switch origin to the SSH URL.

terminal
# 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 main

Private 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.