Session class in orchestrator.py manages the complete lifecycle of an FTL coding task, from snapshot creation through agent execution to diff review and merge.
Session Class
TheSession object coordinates all components:
- Snapshot project state
- Boot or reuse containers
- Inject shadow credentials
- Coordinate parallel agent + test execution
- Compute diffs lazily on demand
- Manage review and merge workflow
Session Lifecycle
1. Initialization
- A unique 8-character trace ID
- Configuration loaded from
.ftlconfigand global defaults - Lazy-initialized sandbox, agent, and diff state
The trace ID appears in all console output and CloudWatch logs, making it easy to correlate events across distributed systems.
2. Snapshot (orchestrator.py:136-143)
The project is snapshotted to ~/.ftl/snapshots/<id> using rsync or S3:
.ftlignore and skip common directories like node_modules, __pycache__, .venv.
3. Shadow Credentials (orchestrator.py:145-177)
FTL generates fake credentials that the agent will see inside the container:
Local mode (default):
secrets_manager_prefix is set):
swap_table maps shadow→real values for use by the optional network proxy.
4. Credential-Swap Proxy (orchestrator.py:166-177)
If cryptography is installed and there are credentials to swap:
- Starts an HTTP/HTTPS MITM server on the host
- Generates an ephemeral CA certificate
- Provides environment variables (
HTTP_PROXY,HTTPS_PROXY,REQUESTS_CA_BUNDLE) to inject into the container - Swaps shadow→real credentials in outbound requests at the network layer
Without the proxy, agents see shadow values in environment variables. Live API calls will fail unless the service happens to accept the fake keys.
5. Agent Authentication (orchestrator.py:180-203)
FTL forwards agent-specific API keys from the host into the container:
6. Sandbox Boot (orchestrator.py:205-231)
- Check disk for persisted container ID (survives process restarts)
- Fall back to class-level standby from earlier in this process
- Create fresh if neither exists
pip install -r requirements.txt) run once and persist in /home/ftl/.local/.
7. Parallel Agent + Test Execution (orchestrator.py:233-274)
The agent and test generator run concurrently:
AgentRenderer parses Claude Code’s stream-json output and displays per-tool progress counters live.
8. Diff Computation (orchestrator.py:286-290)
Diffs are computed lazily — only when first accessed:
9. Merge Workflow (orchestrator.py:321-384)
Lint scan:
- Hardcoded shadow credentials
- Known credential patterns (Stripe keys, AWS keys, GitHub PATs, etc.)
- Dangerous SQL (
DROP TABLE,TRUNCATE,DELETE FROMwithoutWHERE) - Dangerous shell (
rm -rf,chmod -R 777, etc.)
guardrail_id is set):
10. Cleanup (orchestrator.py:398-411)
Interactive Mode
Follow-up Instructions (orchestrator.py:292-304)
- Continue the same agent conversation in the same container
- Invalidate cached diffs (will recompute on next
show_diff()ormerge()) - No snapshot/boot overhead — the container is already warm
Manual Commands
Show diff:One-Shot Mode (orchestrator.py:437-448)
ftl code "task" — starts a session, runs the task, auto-triggers merge/review, then exits.
State Management
Tracing and Logging
CloudWatch events (whencloudwatch_log_group is set):
~/.ftl/logs.jsonl):
Performance Optimizations
- Persistent containers — No cold-boot overhead after first task
- Parallel test generation — Zero wall-clock time added for tests
- Lazy diff computation — Only computed when needed
- Node.js pre-warm — Background thread loads Claude Code into page cache during boot
- Linux-internal diff — Runs inside container, avoids host-side VirtioFS overhead
Next Steps
Agent Adapters
How agents execute tasks inside the sandbox
Sandbox Internals
Container lifecycle, workspace management, and diff computation