SYLLIPTOR

Local CLI coding agent that turns plans into reviewed, PR-ready code.

Bring your own model. Sandboxed by default.

Website · Docs · Changelog

Why Sylliptor

• Forge — Plan, dispatch parallel workers, verify each task, ship.
• Personas — Switch between coding, architecture, questions, and debugging without leaving the session.
• Cross-run memory — Failures become structured issues the next run avoids.
• Flexible model access — Connect your own provider, a supported subscription, or a Sylliptor account.
• Sandboxed by default — Docker or Bubblewrap. An always-on denylist refuses rm -rf /, curl | sh, and sudo — even in fullaccess.

How Forge Works

Type /forge, describe what you want, and Forge:

1. Asks 1–3 clarifying questions if the ask is vague.
2. Writes plan.json with explicit tasks and runnable file scope.
3. On /execute plan, dispatches a swarm of workers that run tasks in parallel.
4. Verifies each task before marking it done. Failures become issue entries the next attempt sees.
5. Integrates verified task changes into the branch where Forge started.

All plans, traces, and per-task artifacts persist under .sylliptor/runs/<run_id>/. Resume any time with /forge resume.

Install

Sylliptor requires Python 3.11 or newer.

pipx install sylliptor-agent-cli

If your default python3 is older than 3.11:

pipx install --python python3.12 sylliptor-agent-cli

pip also works inside a virtual environment:

python -m pip install sylliptor-agent-cli

Quick Start

pipx install sylliptor-agent-cli
cd /path/to/project
sylliptor

The first launch guides you through connecting a model and choosing a workspace. After that, Sylliptor opens directly into an interactive session.

Use /login to connect an account or supported subscription, and /config to change the provider, model, or other session defaults.

Inside Sylliptor

You can ask naturally for the work you want. Sylliptor inspects the workspace, proposes a plan when needed, makes changes within the selected mode, and verifies the result.

Personas

Personas change how Sylliptor approaches a task without changing the safety rules underneath it. Open /persona to choose:

• Code for implementation work.
• Architect for plans and design decisions.
• Ask for read-only questions and explanations.
• Debug for reproduce-first investigation and fixes.

You can switch at any time during a normal session.

Execution Modes

Open /mode to choose how much Sylliptor can do without asking first.

Sandbox & Safety

Shell and verification execution run inside a hardened Docker or Bubblewrap sandbox by default. Shell commands and verification commands default to strict sandboxing. To deliberately disable verification sandboxing for a trusted local setup, set verify_sandbox.mode="off" or SYLLIPTOR_VERIFY_SANDBOX_MODE=off.

docker pull ghcr.io/alysisai/sylliptor-sandbox:dev
docker pull ghcr.io/alysisai/sylliptor-sandbox:server

Prepare or diagnose:

sylliptor sandbox setup
sylliptor sandbox doctor --smoke
sylliptor sandbox pull

The denylist is always-on across every mode. It refuses rm -rf /, curl ... | sh, sudo, force-push to main / master, raw disk writes, fork-bombs, recursive chmod 777 /, and direct > /dev/sd* redirects. In fullaccess, every successful shell command additionally writes a JSONL audit event.

Outbound HTTP from web tools and MCP OAuth goes through safe_http_request with SSRF guards: rejects non-HTTP schemes, loopback / link-local / private / multicast targets across IPv4 and IPv6, validates redirects, and enforces a streamed byte cap.

See Shell sandbox for backend requirements, image cosign signatures, SLSA provenance, and production pinning. See Security model for the full threat boundary.

Extend Sylliptor

Six capability surfaces. Four of them — skills, custom tools, MCP servers, hooks — bundle into a single declarative .toml plugin manifest.

• MCP — connect stdio or Streamable HTTP MCP servers, with OAuth, frozen catalogs, and narrowing-only project overrides.
• Custom tools — drop Python scripts into .sylliptor/tools/*.py. AST-only discovery, trust-keyed by file hash.
• Skills — SKILL.md instruction bundles. Native + interop roots (.sylliptor_skills/, .agents/skills/, .claude/skills/, .github/skills/).
• Subagents — focused delegation. Drop YAML+markdown into .sylliptor_agents/*.md for custom agents. Built-ins: explorer, implementer, frontend-engineer, debugger, code-reviewer, test-strategist, plus the opt-in visual-designer image generator.
• Hooks — lifecycle policy across 11 events (PreToolUse, PostToolUse, SessionStart, ...). Three trust layers.
• Plugins — declarative bundles of skills + custom tools + MCP servers + hooks. Pinned install (registry id or git+https://...@<sha40>).

Run as an HTTP service with Server mode — worker jobs, uploads, queues, and authentication.

Repo conventions. Sylliptor reads AGENTS.md, CLAUDE.md, and CONVENTIONS.md from your repo root as read-only project context.

Configuration & Credentials

Open /login to connect an account or supported subscription. Use /config for API-key providers, model selection, and session defaults. Credentials are stored outside the project.

See Credentials for key resolution and storage details. See Providers and models for additional connection options.

Workspace Behavior

Sylliptor binds a workspace when the session starts. In a git repository, it uses the repository root while preserving the directory where you launched it as the focus directory.

Broad directories such as your home directory require explicit confirmation. The filesystem root is blocked as a workspace.

Project Links

• Website
• Docs index
• Changelog
• Contributing
• Security policy
• License

Use Python 3.11 or newer for local development. See CONTRIBUTING.md for setup and PR expectations. Report vulnerabilities through SECURITY.md, not public GitHub issues.

Sylliptor is distributed under the Apache License 2.0.