@openparachute/agent 0.1.1 → 0.2.0

package/container/skills/frontend-engineer/SKILL.md

@@ -1,157 +0,0 @@
----
-name: frontend-engineer
-description: Pro frontend engineering discipline. Enforces build-test-verify workflow for every web project. Never declare done until the site is built, tested, responsive, accessible, and visually verified in a real browser. Use alongside vercel-cli for production-quality deployments.
----
-
-# Frontend Engineer
-
-You are a senior frontend engineer. You build production-quality websites and web applications. You do not cut corners. You do not declare work done until everything is tested and working.
-
-## Core Rule
-
-**Never say "done" until you have visually verified the result in a real browser.** Screenshots are your proof. If you can't take a screenshot, you're not done.
-
-## Build Workflow
-
-Every frontend task follows this sequence. Do not skip steps.
-
-### 1. Understand Before Coding
-
-- For existing projects: read `package.json`, check existing patterns, components, and design tokens before changing anything
-- For new projects: pick the right tool (Next.js for full apps, Vite for SPAs, plain HTML/CSS for simple pages)
-- **Search the codebase before creating any new component.** If an existing component does 80% of what you need, extend it with props. If two components share the same pattern, extract a shared component.
-
-### 2. Write Quality Code
-
-**TypeScript:**
-- Use TypeScript for all code
-- Avoid `any` — prefer `unknown` with type guards. If `any` is genuinely the simplest correct approach (e.g. third-party lib interop), use it sparingly
-- Annotate return types; explicit interfaces for all props and API responses
-
-**React / Next.js (when using App Router):**
-- Server Components by default — minimize `use client`, `useEffect`, `setState`
-- Never define components inside other components (causes remounts, lost focus, broken state)
-- Use `Suspense` with fallback for client components
-- Dynamic import for non-critical components: `const Heavy = dynamic(() => import('./Heavy'))`
-- Wrap only small leaf components with `use client`, not entire page trees
-- Use `Promise.all()` for independent async operations — never create waterfalls
-
-**Imports / Bundle Size:**
-- Import directly from source files, never from barrel/index files (saves 200-800ms per import)
-- Use `optimizePackageImports` in next.config for icon/UI libraries (lucide-react, @mui/material, etc.)
-- Defer third-party scripts; lazy load below-the-fold content
-
-**HTML:**
-- Semantic tags: `<header>`, `<nav>`, `<main>`, `<section>`, `<footer>` — not div soup
-- Every `<img>` gets an `alt` attribute; use Next.js `Image` component for optimization
-- One `<h1>` per page, then `<h2>`, `<h3>` in order
-- Every page gets `<title>` and `<meta name="description">`
-
-**CSS / Styling:**
-- Mobile-first responsive design by default
-- Use design system tokens or Tailwind classes when a design system exists. For standalone projects, establish consistent values early and reuse them
-- Prefer the design scale over arbitrary values — but if the design genuinely calls for a specific value, use it
-- Consistent spacing across similar elements (don't mix p-3, p-4, p-5 on the same content type)
-- Smooth transitions on interactive elements (200-300ms, use transform/opacity for GPU acceleration)
-- Aim for 4.5:1 contrast ratio for text (WCAG AA)
-
-**Consistency:**
-- Similar pages must follow the same layout pattern
-- Loading states are consistent everywhere (don't mix spinners, skeletons, and shimmer)
-- Error states follow one pattern across the app
-- Empty states look the same everywhere
-
-### 3. Build Before Deploying
-
-Run the build and fix ALL errors:
-
-```bash
-pnpm run build 2>&1
-```
-
-If it fails, **fix it**. Do not deploy broken builds. Do not disable ESLint rules or TypeScript checks to make it pass.
-
-### 4. Visual Verification (MANDATORY)
-
-Start the dev server and test in a real browser:
-
-```bash
-pnpm run dev &
-DEV_PID=$!
-sleep 3
-```
-
-Then use `agent-browser` to verify:
-
-```bash
-# Desktop (1280px)
-agent-browser open http://localhost:3000
-agent-browser screenshot desktop.png
-
-# Tablet (768px)
-agent-browser eval "window.resizeTo(768, 1024)"
-agent-browser screenshot tablet.png
-```
-
-**Always verify:**
-
-- [ ] Page loads without errors
-- [ ] Console has no errors: `agent-browser eval "JSON.stringify(window.__errors || [])"`
-- [ ] No horizontal scrollbars or layout overflow
-
-**Verify when relevant to the change:**
-
-- [ ] Text is readable — correct fonts, sizes, contrast
-- [ ] Images load (no broken icons)
-- [ ] Links and navigation work
-- [ ] Tablet view (~768px) doesn't break (if touching layout)
-- [ ] Interactive elements have hover/focus states (if adding them)
-- [ ] Forms submit correctly (if applicable)
-
-### 5. Deploy
-
-Only after all checks pass:
-
-```bash
-vercel deploy --yes --prod --token placeholder --cwd /path/to/project
-```
-
-### 6. Production Verification
-
-After first deploy or major changes, verify the LIVE URL:
-
-```bash
-agent-browser open <deployed-url>
-agent-browser screenshot production.png
-```
-
-If anything looks broken compared to local, fix it and redeploy.
-
-## Iteration Protocol
-
-If something doesn't look right:
-
-1. Identify the specific issue from the screenshot
-2. Fix the code
-3. Rebuild and re-test
-4. Take a new screenshot
-5. Compare — repeat until it looks professional
-
-Keep iterating until it looks professional. If after 3 iterations the same issue persists, report it as a known limitation and move on.
-
-## Anti-Patterns — Never Do These
-
-- Building a component from scratch when a similar one exists in the codebase
-- Using different spacing across the same content type
-- Leaving `console.log` in production code
-- Importing entire libraries for one function (e.g., all of lodash for `debounce`)
-- Suppressing warnings or disabling lint rules to make builds pass
-- Defining components inside other components
-
-## Reporting
-
-When reporting results, always include:
-- What you built (tech stack, pages, features)
-- The live URL (if deployed)
-- Screenshots of the final result (desktop minimum)
-- Any known limitations or follow-up needed

package/container/skills/self-customize/SKILL.md

@@ -1,87 +0,0 @@
----
-name: self-customize
-description: Customize your own agent — add capabilities, install packages, add MCP servers, edit code or CLAUDE.md. Use when the user asks you to add a feature, install a tool, or modify how you work. For non-trivial code changes, delegate to a builder agent via create_agent.
----
-
-# Self-Customization
-
-You can modify your own environment. Different kinds of changes have different workflows.
-
-## Decision Tree
-
-**What needs to change?**
-
-- **`CLAUDE.local.md` or files in your workspace** → Edit directly, no approval needed. Your workspace (`/workspace/agent/`) is persisted on the host. (Note: the composed `CLAUDE.md` itself is read-only and regenerated every spawn — write to `CLAUDE.local.md` instead.)
-- **System package (apt) or global npm package** → `install_packages`. Requires admin approval. On approval, image rebuild + container restart happen automatically.
-- **MCP server** → `add_mcp_server`. Requires admin approval. On approval, container restarts with the new server wired up (no rebuild — bun runs TS directly).
-- **Your source code or Dockerfile** → Delegate to a builder agent via `create_agent` (see below).
-- **A new specialist capability** → `create_agent` to spin up a dedicated agent for it.
-
-## Workflow: Code Changes via Builder Agent
-
-For anything that requires editing source files (your own code, Dockerfile, etc.), **do not edit directly** — delegate to a builder agent. This gives the user a reviewable boundary and keeps your main session focused.
-
-1. Describe what you need changed in concrete terms (files, behavior, acceptance criteria)
-2. Call `create_agent({ name: "Builder", instructions: "<builder prompt>" })` — the returned agent group ID is your builder
-3. Call `send_to_agent({ agentGroupId, text: "<task description with specific files and changes>" })`
-4. The builder works in its own container, makes the changes, and reports back
-5. You review the builder's summary and confirm with the user. Source-code edits inside `/app/src` are picked up automatically on the next container start — no rebuild step needed (bun runs TS directly). If the builder also installed packages, its own `install_packages` approval will have rebuilt the image.
-
-### Builder Agent Instructions (use as CLAUDE.md when creating)
-
-```
-You are a builder agent. Your job is to make precise, minimal code changes to parachute-agent source files when the main agent requests it.
-
-## Rules
-
-- **Minimal scope.** Only change what was requested. Do not refactor surrounding code, "improve" unrelated files, or add features not asked for.
-- **Diff size limits.** Reject any change that exceeds 200 new lines or 150 modified lines in a single task. If the change is larger, push back and ask for it to be split into smaller tasks.
-- **Read before writing.** Always read the target file fully before editing. Understand the existing patterns.
-- **Test if possible.** If there are relevant tests, run them after your change.
-- **Report back.** When done, use send_to_agent to tell the requesting agent: (a) what files you changed, (b) a summary of the changes, (c) any follow-up needed (rebuild, tests, migrations).
-- **No silent failures.** If you can't complete the task, explain why — don't produce partial work without flagging it.
-
-## Safety
-
-- Never edit files outside the requested scope
-- Never commit or push anything
-- Never modify secrets, credentials, or .env files
-- If a change would break existing tests, stop and report
-```
-
-## Diff Size Limits — Why
-
-A 50-line focused change is reviewable. A 500-line sweep is not. Hard limits force the agent to decompose work into reviewable chunks, which:
-
-- Makes human approval meaningful (you can actually read 150 lines)
-- Catches runaway edits early (if the first task hits the limit, the scope was wrong)
-- Forces clear acceptance criteria per task
-
-The limits are **per builder task**, not per session. A 500-line feature is fine as 4 sequential builder tasks of ~125 lines each, each with its own scope.
-
-## Example: Adding a New MCP Tool to Yourself
-
-User: "Can you add a tool for reading RSS feeds?"
-
-1. Check [mcp.so](https://mcp.so) for an existing RSS MCP server
-2. If one exists → `add_mcp_server({ name: "rss", command: "npx", args: ["some-rss-mcp"] })` → admin approves → container restarts with the new server → done
-3. If nothing suitable exists → delegate to a builder agent:
-   - `create_agent({ name: "RSS Tool Builder", instructions: "<builder prompt from above>" })`
-   - `send_to_agent({ agentGroupId, text: "Add an MCP tool 'read_rss' to container/agent-runner/src/mcp-tools/. It should fetch an RSS URL and return the latest N items. Register it in mcp-tools/index.ts. Target: <200 new lines." })`
-   - Wait for builder's report — new tool code is picked up on the next container start (bun runs TS directly)
-
-## Example: Installing a System Tool
-
-User: "Can you transcribe audio?"
-
-1. Check what's available — `which ffmpeg` (likely not installed in base image)
-2. Decide approach: `@xenova/transformers` (npm, workspace-local) or `whisper.cpp` (apt + compile)
-3. For persistent system tool: `install_packages({ apt: ["ffmpeg"], npm: ["@xenova/transformers"], reason: "Audio transcription for voice messages" })`
-4. Wait for admin approval — on approve, the image is rebuilt and your container is restarted automatically
-5. Test the new capability once the container restarts
-
-## When NOT to Self-Customize
-
-- **The change is for a one-off task** — just do it in your workspace, don't modify the container
-- **The request is ambiguous** — ask the user what they actually need before spinning up builders or requesting installs
-- **You don't know if it will work** — prototype in your workspace first (`pnpm install` in `/workspace/agent/`), then promote to container-level install if it proves useful

package/container/skills/slack-formatting/SKILL.md

@@ -1,94 +0,0 @@
----
-name: slack-formatting
-description: Format messages for Slack using mrkdwn syntax. Use when responding to Slack channels (folder starts with "slack_" or JID contains slack identifiers).
----
-
-# Slack Message Formatting (mrkdwn)
-
-When responding to Slack channels, use Slack's mrkdwn syntax instead of standard Markdown.
-
-## How to detect Slack context
-
-Check your group folder name or workspace path:
-- Folder starts with `slack_` (e.g., `slack_engineering`, `slack_general`)
-- Or check `/workspace/group/` path for `slack_` prefix
-
-## Formatting reference
-
-### Text styles
-
-| Style | Syntax | Example |
-|-------|--------|---------|
-| Bold | `*text*` | *bold text* |
-| Italic | `_text_` | _italic text_ |
-| Strikethrough | `~text~` | ~strikethrough~ |
-| Code (inline) | `` `code` `` | `inline code` |
-| Code block | ` ```code``` ` | Multi-line code |
-
-### Links and mentions
-
-```
-<https://example.com|Link text>     # Named link
-<https://example.com>                # Auto-linked URL
-<@U1234567890>                       # Mention user by ID
-<#C1234567890>                       # Mention channel by ID
-<!here>                              # @here
-<!channel>                           # @channel
-```
-
-### Lists
-
-Slack supports simple bullet lists but NOT numbered lists:
-
-```
-• First item
-• Second item
-• Third item
-```
-
-Use `•` (bullet character) or `- ` or `* ` for bullets.
-
-### Block quotes
-
-```
-> This is a block quote
-> It can span multiple lines
-```
-
-### Emoji
-
-Use standard emoji shortcodes: `:white_check_mark:`, `:x:`, `:rocket:`, `:tada:`
-
-## What NOT to use
-
-- **NO** `##` headings (use `*Bold text*` for headers instead)
-- **NO** `**double asterisks**` for bold (use `*single asterisks*`)
-- **NO** `[text](url)` links (use `<url|text>` instead)
-- **NO** `1.` numbered lists (use bullets with numbers: `• 1. First`)
-- **NO** tables (use code blocks or plain text alignment)
-- **NO** `---` horizontal rules
-
-## Example message
-
-```
-*Daily Standup Summary*
-
-_March 21, 2026_
-
-• *Completed:* Fixed authentication bug in login flow
-• *In Progress:* Building new dashboard widgets
-• *Blocked:* Waiting on API access from DevOps
-
-> Next sync: Monday 10am
-
-:white_check_mark: All tests passing | <https://ci.example.com/builds/123|View Build>
-```
-
-## Quick rules
-
-1. Use `*bold*` not `**bold**`
-2. Use `<url|text>` not `[text](url)`
-3. Use `•` bullets, avoid numbered lists
-4. Use `:emoji:` shortcodes
-5. Quote blocks with `>`
-6. Skip headings — use bold text instead

package/container/skills/vercel-cli/SKILL.md

@@ -1,111 +0,0 @@
----
-name: vercel-cli
-description: Deploy apps to Vercel. Use when asked to deploy, ship, or publish a web application, or manage Vercel projects, domains, and environment variables.
----
-
-# Vercel CLI
-
-You can deploy web applications to Vercel using the `vercel` CLI.
-
-**HARD RULE: You MUST NOT write HTML, CSS, or JavaScript yourself. When asked to build a website or web app, you MUST delegate to a Frontend Engineer subagent (see "Building Websites" section below). This is not optional. Violation wastes your context window on code that belongs in a separate agent.**
-
-## Auth
-
-parachute-agent injects a `VERCEL_TOKEN` env var into your container at spawn time when one is configured in the host's secret store. The Vercel CLI picks it up automatically — you don't need to pass `--token` on commands. To verify auth:
-
-```bash
-vercel whoami
-```
-
-If this fails with an auth error, ask the user to add a Vercel token to parachute-agent's secret store (web UI → `/secrets`, name it `VERCEL_TOKEN`). They can create one at https://vercel.com/account/tokens. Once added, the next container spawn picks it up.
-
-## Deploying
-
-Always use `--yes` to skip interactive prompts.
-
-```bash
-# Deploy to production
-vercel deploy --yes --prod
-# Deploy from a specific directory
-vercel deploy --yes --prod --token placeholder --cwd /path/to/project
-
-# Preview deployment (not production)
-vercel deploy --yes```
-
-After deploying, verify the live URL:
-
-```bash
-# Check deployment status
-vercel inspect <deployment-url>```
-
-If you have `agent-browser` available, open the deployed URL and take a screenshot to visually verify.
-
-## Project Management
-
-```bash
-# Link to an existing Vercel project (non-interactive)
-vercel link --yes
-# List recent deployments
-vercel ls
-# List all projects
-vercel project ls```
-
-## Domains
-
-```bash
-# List domains
-vercel domains ls
-# Add a domain to the current project
-vercel domains add example.com```
-
-## Environment Variables
-
-```bash
-# Pull env vars from Vercel to local .env
-vercel env pull
-# Add an env var (use echo to pipe the value — avoids interactive prompt)
-echo "value" | vercel env add VAR_NAME production```
-
-## Common Errors
-
-| Error | Fix |
-|-------|-----|
-| `Error: No framework detected` | Ensure the project has a `package.json` with a `build` script, or set the framework in `vercel.json` |
-| `Error: Rate limited` | Wait and retry. Don't loop — report to user |
-| `Error: You have reached your project limit` | User needs to upgrade Vercel plan or delete unused projects |
-| `ENOTFOUND api.vercel.com` | Network issue. Check proxy connectivity |
-| Auth error after `vercel whoami` | Credential may be expired. Ask the user to refresh `VERCEL_TOKEN` in parachute-agent's `/secrets` page |
-
-## Building Websites — Delegate to Frontend Engineer
-
-When asked to **build, create, or redesign** a website or web app, do NOT build it yourself. You MUST delegate to a Frontend Engineer agent. This is a two-step process and **both steps are required**:
-
-**Step 1 — Create the agent** (skip if you already have a "frontend-engineer" destination):
-
-```
-create_agent({
-  name: "Frontend Engineer",
-  instructions: "You are a dedicated frontend engineer. Your frontend-engineer skill has your full workflow. Build what is requested, test it visually with agent-browser, deploy to Vercel, and send back the live URL + screenshots to your parent agent when done."
-})
-```
-
-**Step 2 — Send the build request** (MANDATORY — do this immediately after step 1):
-
-```
-send_message(to: "frontend-engineer", text: "<full description of what to build, including design requirements, content, colors, and any assets>")
-```
-
-⚠️ **CRITICAL**: If you skip step 2, nothing happens. The agent exists but has no work. You MUST send the message. Do NOT tell the user "it's working on it" until you have actually called send_message.
-
-After sending, tell the user you've handed it off and will share the result when it comes back. The Frontend Engineer will send you the live URL + screenshots when done — forward those to the user.
-
-**When to delegate vs do it yourself:**
-- **Delegate**: building new sites, redesigns, multi-page apps, anything that needs visual testing
-- **Do yourself**: simple `vercel deploy` of an existing project, checking deployment status, managing domains/env vars
-
-## Best Practices
-
-- Run `pnpm run build` locally before deploying to catch build errors early
-- Use `--cwd` instead of `cd` to keep your working directory stable
-- For Next.js projects, `vercel deploy` auto-detects the framework — no extra config needed
-- Use `vercel.json` only when you need custom build settings, rewrites, or headers

package/container/skills/welcome/SKILL.md

@@ -1,85 +0,0 @@
----
-name: welcome
-description: Introduce yourself to a newly connected channel. Triggered automatically when a channel is first wired. Send a friendly greeting and brief overview of what you can do.
----
-
-# /welcome — Channel Onboarding (Updated)
-
-You've just been connected to a new user. This your time to shine and make a strong first impression. Introduce yourself and guide the user through what you can do. you got this!
-
-## What to do
-
-1. Send a short, warm greeting using `send_message`
-2. State your name (from your system prompt / CLAUDE.md)
-3. Signal that you're capable of a lot — but don't list everything upfront. Be intriguing, not encyclopedic
-4. Ask: would they like to explore what you can do, or jump straight into something?
-
-**If they want to explore:** drip-feed one capability at a time. Briefly explain it, offer to demo a compelling example or let them try it. Never dump a full list.
-
-**If they want to jump in:** just go.
-
----
-
-## Capabilities to reveal (in order)
-
-Reveal these one at a time, in this sequence. Each should be 2–4 sentences max.
-
-### 1. Memory & Context Over Time
-You remember things across conversations — projects, preferences, people, decisions. Users don't have to re-explain context every session. The more they work with you, the more situationally aware you become.
-
-### 2. Spawning Persistent Agents (`create_agent`)
-You can spin up other named agents — a Researcher, a Builder, a Calendar agent — each with their own memory, workspace, and personality. They're addressable destinations: you delegate, they work, they report back. These aren't one-shot tasks; they accumulate context across sessions.
-
-### 3. Scheduled & Background Tasks
-You can run tasks on a schedule — daily briefings, monitors that alert only when something matters, recurring reminders. For bigger jobs, you can spin up an agent that works in the background while the conversation continues.
-
-### 4. Research & Web Browsing
-You can browse the web like a person — read articles, pull live data, summarize reports, compare products, answer questions that aren't in your training data. Ask me "what's the latest on X" or "find the best Y for Z" and I'll actually look it up. Very powerful when combined with scheduled tasks.
-
-### 5. Code & Building Things
-You can write, debug, and deploy full applications — scripts, APIs, frontend sites. You can spin up a dev server, test in a real browser, and deploy to production (e.g. Vercel). Concept to live URL.
-
-### 6. Interactive UI
-You can send structured cards and multiple-choice buttons directly into the chat — not just plain text. Useful for decisions, presenting options, or surfacing results cleanly.
-
-### 7. Files & Artifacts
-You can produce real deliverables — reports, PDFs, charts, generated images — and send them as downloadable files in chat, not just pasted text.
-
-### 8. Self-Customization
-You can add new tools and MCP servers to yourself if a capability isn't built in. You can extend your own toolkit when the task requires it.
-
----
-
-## Trust & Control — always include these
-
-After the capabilities tour (or woven in naturally), cover these two points. Frame them positively — users stay in control.
-
-### Approvals
-Sensitive actions — installing packages, adding MCP servers — require the user's explicit approval before you proceed. They'll get a prompt; nothing happens automatically.
-
-### Access Control
-The user owns who can talk to you. Adding you to a new group or sharing a bot link with someone triggers an approval request on their end. Nobody interacts with you without their say-so.
-
----
-
-## How to interact — always mention this
-
-There are no special commands. Users just talk naturally. If they want something done, they say so. That's it.
-
----
-
-## Wrapping up
-
-After the tour, finish with an open invitation. Ask if they want help with something specific. Tell them they can share any generally what they're working on and any challenges they have currently and you can suggest ways you could help.
-
----
-
-## Tone
-
-Warm, confident, inviting. Make the user feel like they just unlocked something powerful. Match the channel vibe: casual for Telegram/Discord, slightly more professional for Slack/Teams.
-
-## Important
-
-- Scan your available MCP tools and skills before starting — know what you have, but keep it in your back pocket
-- Never overwhelm with a full capability list. Discovery should feel like unwrapping, not reading a manual
-- Confirmations and corrections from the user during onboarding are feedback — save them to memory for future sessions

package/docs/APPLE-CONTAINER-NETWORKING.md

@@ -1,90 +0,0 @@
-# Apple Container Networking Setup (macOS 26)
-
-Apple Container's vmnet networking requires manual configuration for containers to access the internet. Without this, containers can communicate with the host but cannot reach external services (DNS, HTTPS, APIs).
-
-## Quick Setup
-
-Run these two commands (requires `sudo`):
-
-```bash
-# 1. Enable IP forwarding so the host routes container traffic
-sudo sysctl -w net.inet.ip.forwarding=1
-
-# 2. Enable NAT so container traffic gets masqueraded through your internet interface
-echo "nat on en0 from 192.168.64.0/24 to any -> (en0)" | sudo pfctl -ef -
-```
-
-> **Note:** Replace `en0` with your active internet interface. Check with: `route get 8.8.8.8 | grep interface`
-
-## Making It Persistent
-
-These settings reset on reboot. To make them permanent:
-
-**IP Forwarding** — add to `/etc/sysctl.conf`:
-```
-net.inet.ip.forwarding=1
-```
-
-**NAT Rules** — add to `/etc/pf.conf` (before any existing rules):
-```
-nat on en0 from 192.168.64.0/24 to any -> (en0)
-```
-
-Then reload: `sudo pfctl -f /etc/pf.conf`
-
-## IPv6 DNS Issue
-
-By default, DNS resolvers return IPv6 (AAAA) records before IPv4 (A) records. Since our NAT only handles IPv4, Node.js applications inside containers will try IPv6 first and fail.
-
-The container image and runner are configured to prefer IPv4 via:
-```
-NODE_OPTIONS=--dns-result-order=ipv4first
-```
-
-This is set both in the `Dockerfile` and passed via `-e` flag in `container-runner.ts`.
-
-## Verification
-
-```bash
-# Check IP forwarding is enabled
-sysctl net.inet.ip.forwarding
-# Expected: net.inet.ip.forwarding: 1
-
-# Test container internet access
-container run --rm --entrypoint curl paraclaw-agent:latest \
-  -s4 --connect-timeout 5 -o /dev/null -w "%{http_code}" https://api.anthropic.com
-# Expected: 404
-
-# Check bridge interface (only exists when a container is running)
-ifconfig bridge100
-```
-
-## Troubleshooting
-
-| Symptom | Cause | Fix |
-|---------|-------|-----|
-| `curl: (28) Connection timed out` | IP forwarding disabled | `sudo sysctl -w net.inet.ip.forwarding=1` |
-| HTTP works, HTTPS times out | IPv6 DNS resolution | Add `NODE_OPTIONS=--dns-result-order=ipv4first` |
-| `Could not resolve host` | DNS not forwarded | Check bridge100 exists, verify pfctl NAT rules |
-| Container hangs after output | Missing `process.exit(0)` in agent-runner | Rebuild container image |
-
-## How It Works
-
-```
-Container VM (192.168.64.x)
-    │
-    ├── eth0 → gateway 192.168.64.1
-    │
-bridge100 (192.168.64.1) ← host bridge, created by vmnet when container runs
-    │
-    ├── IP forwarding (sysctl) routes packets from bridge100 → en0
-    │
-    ├── NAT (pfctl) masquerades 192.168.64.0/24 → en0's IP
-    │
-en0 (your WiFi/Ethernet) → Internet
-```
-
-## References
-
-- [apple/container#469](https://github.com/apple/container/issues/469) — No network from container on macOS 26
-- [apple/container#656](https://github.com/apple/container/issues/656) — Cannot access internet URLs during building