How checkpoints are stored

Checkpoint commits use git's own object model underneath, but are deliberately kept out of your way while you use git yourself in the same repository. They are created with a temporary, throwaway index file rather than your project's real staging area.

This means a checkpoint never interferes with anything you are doing with git in parallel, a change you have staged but not committed, a branch you are mid-rebase on, none of it is touched or disturbed by tCode creating a checkpoint underneath it.

Checkpoints also never move your branch or your HEAD. They exist purely as commit objects sitting in the repository's object database, waiting for /rewind to restore from them later, not as part of your project's visible, normal commit history.

Because a checkpoint is a real git commit object rather than a copy of files kept somewhere else, it benefits from the same storage efficiency git already applies to every commit, only the actual changes between one snapshot and the next add meaningfully to the repository's size, not a full duplicate of every file each time.

You will not see checkpoint commits if you run git log in the normal way, since they are never attached to a branch reference; they exist in the object database but are not part of any ref that ordinary git commands walk by default.