Docs · Your code

Your code

The workspace sboot start creates is a normal git repo on your machine — not a checkout of ours, not a sandbox, not a mirror of something we hold. Everything under your source tree — os/ in the OS courses, db/ in the SQLite course, game/ in the word game; the README in your repo names it — is yours: you wrote it, you own it, and the scaffold it started from is MIT-licensed so you can publish, fork and build on it freely. The course's tests and the grading engine are deliberately not in the repo — they live in the SourceBoot data directory (sboot where prints both paths) — so publishing the repo publishes your work and nothing else.

We hold no credentials for your repo, request no repository permissions, and never push, pull or clone it. GitHub sign-in on the site is identity only.

Make it a repo

Half of it is already done: sboot start ran git init inside your workspace and made the first commit there, without going near GitHub. Putting it on GitHub is a separate command, sboot repo, and it is the only place that does so:

gh repo create kernel-sb --private --source . --push

That is the whole mechanism — GitHub's CLI runs it on your machine, with your gh credential, and there is no server side to it. If gh is installed but not signed in, sboot repo runs gh auth login for you first, in the terminal you are already in. Declining costs nothing, and it never touches a remote you have already set.

Without gh, it offers the install line for your machine — or the manual path: a prefilled github.com/new link, then

cd kernel-sb
git remote add origin https://github.com/<you>/kernel-sb.git
git push -u origin main

The cd is not decoration: run those from one directory up and the repo you push is the parent folder. And GitHub will ask that push for a token, not your password — sboot repo links you to GitHub's own page on making one.

Host it wherever you like, private or public — GitHub, elsewhere, or nowhere. The course does not care whether the repo exists; committing as you go is a habit worth having and the reason the offer is made at all.

Or start from the GitHub template

The kernel-in-rust course's starter tree is also published as a public GitHub template repo, so your kernel can begin life as a repo you own, stamped "generated from sourceboot/kernel-in-rust-starter":

gh repo create my-os --private --template sourceboot/kernel-in-rust-starter --clone
cd my-os
sboot test

The clone is already a working workspace — sboot recognises it by its sboot.toml and fetches the lab's tests on first use. To pull the tests and the grading engine down deliberately, and prove the machine works before you start, run sboot resume my-os: it checks the workspace, fetches what a clone is always missing, and grades the first lab. Both ways in produce the same files.

What you don't need here is sboot start. Run inside the clone it is harmless — it repairs, restoring anything absent and touching nothing you wrote — but run one directory up it would create a second workspace beside this one, under the name it picks itself: ./kernel-sb/, after the thing you finish with rather than after the course or your clone.

What ever leaves your machine

Only when you run the command that sends it:

  • sboot login: this machine's hostname, so the approval page can name what you are approving. It gets back a token, stored 0600 on your machine.
  • bare sboot, sboot courses, sboot whoami: reads — which labs you have completed, and the catalog. Nothing of yours is sent.
  • sboot test (online): the practice score and per-check pass/fail lines. Never your source.
  • sboot submit: your source tree (build artifacts and .git excluded) plus the captured result of your local run. Both are judged and then dropped once the verdict is written; what is kept is the verdict, your completion, and — on a passing submission — the diff of what you wrote for that lab, because that is what your code review is written on and what the review page shows you afterwards. The full model is in How grading works.
  • sboot hint, sboot where, sboot debug: nothing.

And one thing that is not a command: the code review and the mentor chat on the web. The kept diff, and the files that diff touches, are sent to Anthropic's API — the model that writes your review and its replies — along with whatever you type in the chat. Nothing else about your account travels with them. That is the only third party your code reaches.

The portfolio angle

The repo is the point. The README sboot start writes leads with what you built, the LICENSE is yours to honor as author, and the .gitignore keeps it to source. By the end of a course it is not an exercise folder — it is a working system with a commit history that shows how you got there, in a repo with your name on it. That is a better artifact to show someone than any certificate; the verified completions on your profile are ours to vouch for, and the code is yours to walk them through.