Christian Alfoni christianalfoni

Migration Guide: CodeSandbox Repositories to GitHub Codespaces

1. Vocabulary Mapping

CodeSandbox Term	GitHub Codespaces Term	Difference
Sandbox	Codespace	A Sandbox is the branch. A Codespace is an instance of a branch.
Forking a Sandbox	Creating a Branch	In Codespaces, you create a git branch first, then launch a container for it.
VM Snapshot	Prebuilds	CodeSandbox saves memory state; Codespaces "pre-installs" dependencies so you start fast.
`.codesandbox/tasks.json`	`devcontainer.json` (Scripts)	CodeSandbox uses a dedicated tasks file; Codespaces uses `postCreateCommand` or `postStartCommand`.

TypeScript Architecture Guide: Context Interface Pattern

Core Philosophy

Separate your application into two layers:

Application Logic - Pure TypeScript that describes what happens
Context Interface - Implementations of how things happen (async operations, 3rd party APIs, I/O)

The application should never directly import or call external dependencies. Instead, it receives a Context interface that provides all capabilities it needs.

Short version: If you’re okay with some rules/restrictions, this is very doable. If you want it to work with “totally arbitrary JS inside the component”, it gets hard (full control-flow/data-flow analysis territory).

Let me break it down in terms of what you probably want for Rask, and what the compiler would actually have to do.

⸻

What you have vs what you want

Best Practice Release (2.3.0)

History of Hibernation and Persistence

At CodeSandbox, we built a product where users could treat their sandboxes like cloud-based laptops. When a user stepped away from a project, the sandbox would automatically hibernate after a period of inactivity. Upon resuming, the sandbox would restore to its exact previous state — both in memory and persistence — almost instantly.

Given that most sandboxes were small, short-lived projects, we introduced an automatic archiving mechanism. After 7 days of inactivity, a sandbox would be archived. This system allowed us to manage persistence without requiring user intervention. It was opinionated, reliable, and tailored to a single use case that worked well at our scale.

Additionally, the CodeSandbox product introduced a feature called Live Forking. This allowed users to fork a running sandbox with the new sandbox sharing memory from the original. This enabled seamless flows such as starting in a read-only, always-up-to-date main

Technical Specifications: "Pint" Sandbox Type with Feature Flag Support

Overview

This specification outlines the implementation of a new sandbox type called "pint" in the CodeSandbox platform. The feature enables passing a feature flag from the CodeSandbox SDK through the server to the pitcher-manager during sandbox creation and VM startup processes.

Technical Requirements

Core Requirements

Add support for a new sandbox type identifier: "pint"

RFC: Rethinking Sandbox lifecycles in @codesandbox/sdk

1. History of Hibernation and Persistence

At CodeSandbox, we built a product where users could treat their sandboxes like cloud-based laptops. When a user stepped away from a project, the sandbox would automatically hibernate after a period of inactivity. Upon resuming, the sandbox would restore to its exact previous state — both in memory and persistence — almost instantly.

Given that most sandboxes were small, short-lived projects, we introduced an automatic archiving mechanism. After 7 days of inactivity, a sandbox would be archived. This system allowed us to manage persistence without requiring user intervention. It was opinionated, reliable, and tailored to a single use case that worked well at our scale.

Additionally, the CodeSandbox product introduced a feature called Live Forking. This allowed users to fork a running sandbox with the new sandbox sharing memory from the original. This enabled seamless flows such as starting in a read-o

	<!DOCTYPE html>
	<html lang="en">
	<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>How We Actually Interact With LLMs</title>
	<link rel="preconnect" href="https://fonts.googleapis.com">
	<link href="https://fonts.googleapis.com/css2?family=Space+Mono:wght@400;700&family=Syne:wght@400;600;800&display=swap" rel="stylesheet">
	<style>
	:root {

	w() {
	local branch="$1"
	if [[ -z "$branch" ]]; then
	echo "Usage: w <branch-name>"
	return 1
	fi

	# must be in a git repo
	git rev-parse --is-inside-work-tree >/dev/null 2>&1 \|\| {
	echo "Not in a git repository."

	import {
	Alert,
	Button,
	Card,
	CardBanner,
	CardBody,
	CardHeader,
	HStack,
	VStack,
	} from '@client/component-library'

	import {
	Alert,
	Button,
	Card,
	CardBanner,
	CardBody,
	CardHeader,
	HStack,
	VStack,
	} from "@client/component-library";