How It Works
- Extraction: When a tool returns data with large strings (>
extractionThreshold), those strings are stored in the sidecar and replaced with reference tokens (__ref_abc123) - Lazy Resolution: When script code accesses a reference token, it’s resolved just-in-time to the actual data
- Safe Property Access: Only explicit property accesses trigger resolution, preventing data exfiltration
Basic Configuration
Configuration Options
Reference Token Format
Reference tokens follow this pattern:__ref_abc123def456
Scripts cannot distinguish between reference tokens and regular strings until they access the data.
Security: Composite Blocking
WhenallowComposites: false (default), the sidecar blocks string concatenation with reference tokens:
Use Cases
Large API Responses
Document Processing
Multi-Step Workflows
Memory Management
The sidecar helps manage memory in several ways:- Bounded storage -
maxTotalSizeprevents unbounded growth - Per-reference limits -
maxReferenceSizecaps individual entries - Lazy loading - Data only loaded when accessed
- Automatic cleanup - References cleared after execution
Error Handling
Monitoring Sidecar Usage
Best Practices
- Set appropriate thresholds - Too low creates many references; too high defeats the purpose
- Monitor total size - Track sidecar usage to tune
maxTotalSize - Keep composites disabled - Unless you specifically need string concatenation
- Use with large tool responses - Most beneficial when tools return KB+ of data
Related
- Tool System - Tool integration
- Configuration - All configuration options
- Security Levels - Security presets