Berry Wiki

VS Code Container Wasm GCC Example

Properties2
tagsai, sandboxing
aliasesVscode Container Wasm Gcc Example

7 min read

VS Code Container Wasm GCC Example

Summary

vscode-container-wasm-gcc-example is a four-commit demonstration repository, not a maintained sandbox product. It shows a Debian container with GCC converted to WebAssembly, launched inside github.dev, and controlled through a browser terminal supplied by the experimental vscode-container-wasm extension.

Problem

VS Code for the Web normally cannot run Linux compilers or container commands locally because the browser has no Docker daemon or remote development host. This example demonstrates that a converted container can emulate enough Linux inside WebAssembly to compile and run a small C program without a server-side container.

How It Works

  • Container image: The source image is Debian Sid Slim with GCC installed.

  • Conversion: container2wasm turns the Linux container into a WebAssembly image containing a CPU emulator and guest environment.

  • Browser runtime: The VS Code extension uses a patched vscode-wasm host to execute the image in the browser.

  • Terminal: The extension presents the emulated container through a terminal inside VS Code for the Web.

  • Workspace mount: Repository files appear at /workspace in the guest, allowing GCC to read source files and write compilation output.

  • Network bridge: A browser-side network stack sends supported HTTP and HTTPS requests through the browser Fetch API.

Security Role

  • Browser boundary: Guest instructions run inside WebAssembly rather than as native commands on the user’s operating system.

  • Emulated Linux: This is not a hardware-backed VM. Its boundary depends on the browser, WebAssembly engine, VS Code extension host, patched WASI layer, and emulator.

  • Workspace exposure: The mounted repository is deliberately accessible to guest commands. The example does not document read-only behavior or change-review controls.

  • Browser network policy: Cross-origin rules and forbidden-header restrictions limit HTTP and HTTPS traffic, but they are browser rules rather than an agent-specific destination allowlist.

  • No hardening claim: Neither the example nor extension presents a threat model, security audit, hostile-code guarantee, secret broker, or multi-tenant design.

  • Demonstration only: It should illustrate an execution technique, not serve as evidence that arbitrary agent-generated code is safely contained.

Platforms

  • Client: A modern browser running github.dev with SharedArrayBuffer enabled through the documented cross-origin-isolation query option.

  • Editor: VS Code for the Web with the ktock.container-wasm extension.

  • Guest: Debian Linux with GCC, emulated inside WebAssembly.

  • Repository: The example includes a small C source file and VS Code settings that point at the prepared container image.

  • Coding agents: No agent is bundled. Running Claude Code, Codex, or a full autonomous agent is undocumented and likely constrained by browser performance, networking, persistence, process compatibility, and credentials.

Setup

  • Open: Load the repository through its documented github.dev URL with cross-origin isolation enabled.

  • Install: Add the ktock.container-wasm VS Code extension.

  • Launch: Run the extension’s “Run Container On Browser” command.

  • Use: Compile repository source from the terminal inside the emulated container.

  • Customize: A maintainer can convert another image with container2wasm, host the WebAssembly artifact over HTTP or HTTPS, and update VS Code settings to point to it.

Network and Credentials

  • Modes: The extension offers none and fetch networking; fetch is the default.

  • Protocol scope: Guest networking is limited to HTTP and HTTPS through the browser Fetch API.

  • Browser restrictions: Cross-origin resource sharing rules apply, and guest software cannot control browser-forbidden headers.

  • No raw sockets: The example does not expose a normal unrestricted Linux TCP or UDP network stack to the internet.

  • Credentials: No documented Git token, SSH agent, API-key injection, or secret store exists for the example.

  • Browser risk: Any credential deliberately made visible to guest software should be assumed readable by that software and sendable to permitted web destinations.

Strengths

  • No remote compute: The demonstration runs inside the browser without provisioning a server container or VM.

  • Familiar tooling: A conventional Debian GCC toolchain appears behind a normal terminal.

  • Portable concept: Container images can be converted instead of rewriting every tool directly for WebAssembly.

  • Host separation: Linux commands are not launched as native host processes.

  • Open implementation: The example, extension, and converter are published under open-source licenses.

  • Clear scope: The tiny repository makes the browser-container technique easy to inspect.

Limits

  • Example status: It contains only four commits, one C file, no release, no package, and no product support promise.

  • Inactive repository: The latest commit was in November 2023.

  • Experimental dependency: The extension and container2wasm both label themselves experimental.

  • Slow execution: The README warns that startup and compilation can take time because Linux and its processor are emulated in WebAssembly.

  • Limited network: Only browser-mediated HTTP and HTTPS work, subject to cross-origin restrictions.

  • Browser requirement: SharedArrayBuffer and cross-origin isolation must be available.

  • Agent gaps: There is no lifecycle manager, persistence model, repository write-back policy, credential forwarding, destination allowlist, resource quota, or audit trail.

Activity and Maturity

Checked 2026-07-14.

  • Example repository: Created 2023-11-04, with four commits, nine stars, five forks, no open issues or pull requests, and no releases.

  • Latest example commit: 22ee4676b7086afd7599f5bcb22ece9cd9fe64a5, dated 2023-11-04.

  • Extension: ktock/vscode-container-wasm had 44 commits, 215 stars, ten forks, seven combined open issues and pull requests, and three releases.

  • Latest extension release: v0.0.3, published 2024-03-12. Its repository’s last push was 2025-10-27.

  • Assessment: Useful historical proof of concept. The example itself shows no continuing maintenance and should not be evaluated as production infrastructure.

Best Fit

  • Good fit: Learning how container2wasm, WASI, browser networking, and VS Code for the Web can combine.

  • Good fit: Small demonstrations or education where installing local compilers and provisioning remote compute are undesirable.

  • Poor fit: Autonomous coding agents, production builds, sensitive repositories, high-performance compilation, broad network access, or security-critical untrusted-code execution.

Comparison

  • Versus Container2wasm: Container2wasm is the general converter and runtime technique. This repository is one fixed GCC example consumed by the VS Code browser extension.

  • Versus AgentVM: Both emulate Linux through WebAssembly. AgentVM exposes a Node.js library for agent commands and full TCP/UDP NAT; this example runs in a browser and inherits stricter browser networking.

  • Versus Cloudflare workerd: workerd runs WebAssembly and JavaScript designed for Worker APIs. This example emulates a Linux container so unmodified GCC can run, at much greater size and execution cost.

  • Versus Codespaces: Codespaces supplies a managed Linux VM and development container capable of normal agents and fast native compilers. This example uses only browser resources and is far narrower.

  • Versus Clawk: Clawk provides hardware-backed microVMs, agent lifecycle, repository workflow, and filtered network access. This repository only demonstrates browser-side GCC execution.

Hacker News Context

The Clawk thread linked HN comment 46825119, where user westurner discussed AgentVM, container2wasm, and this VS Code example while comparing ways to run Linux-like environments through WebAssembly. Replies described AgentVM’s full Linux emulation as technically impressive but heavier than lighter WASI approaches. The example supports that technical discussion; it was not presented by its maintainer as a current coding-agent product.

Direct Sources

Unknowns

  • Current functionality: The documented github.dev flow was not interactively executed during this research.

  • Image provenance: The current location, build process, update schedule, and integrity verification for the hosted GCC WebAssembly image need validation.

  • Browser compatibility: Supported browser versions and behavior outside the documented GitHub web editor are not listed.

  • Security assessment: No independent audit or formal escape analysis was found.

  • Resource controls: CPU, memory, storage, and execution-time limits are not documented as enforceable policies.

  • Workspace semantics: Exact persistence, write-back, and permission behavior for the /workspace mount needs live testing.

  • Agent feasibility: No official evidence shows a modern coding-agent command line running successfully in this example.

Sources

    • imported AI research note for Vscode Container Wasm Gcc Example.

Graph View