toolkit command accepts a --json flag that switches its output from human-readable text to structured, machine-parseable JSON. This single flag transforms the CLI into a first-class data source for AI coding agents, CI/CD pipelines, shell scripts, and any automation workflow that needs reliable information about your local development environment. The exit code continues to reflect success or failure regardless of output format, so your existing error-handling logic works without changes.
The --json Flag
Add --json to any Toolkit command to receive structured output instead of the formatted table or prose you’d see in a terminal:
ports, clean, proxy, hosts, autostart, and daemon. The shape of the JSON object is consistent and documented per-command — making it straightforward to build typed interfaces around in any language.
JSON output is written to stdout. Error and warning messages are written to stderr so they never pollute the JSON stream. Your parsing logic can safely read stdout without filtering out diagnostic messages.
Example JSON Outputs
toolkit ports list --json
Returns an array of every port currently in use, with process metadata for each entry:
toolkit clean scan ~/projects --json
Returns a summary of all discovered dependency and virtual environment directories, along with the total recoverable disk space:
toolkit proxy list --json
Returns all active proxy routes registered on the reverse proxy:
toolkit autostart status --json
Returns the current autostart configuration for the running platform:
toolkit ports analyze --json
Returns a diagnostic report of the current port landscape, including detected conflicts between processes and any ports that may collide with well-known services:
Using with AI Coding Agents
AI agents like Cursor, GitHub Copilot Workspace, or custom LLM-powered tools can calltoolkit ports list --json to understand the state of your local environment before taking action. This gives the agent accurate, real-time data rather than relying on assumptions or stale configuration files.
Example workflow — agent scaffolding a new service:
- The agent calls
toolkit ports list --jsonto get all occupied ports. - It parses the response to find a free port in the
3000–4000range. - It generates a configuration file (e.g.,
vite.config.tsor.env) with the chosen port pre-populated. - It calls
toolkit proxy add my-new-service <port>to register the proxy route. - It reports back to the developer: “Started your service on port 3001, accessible at http://my-new-service.localhost.”
Port Awareness
Call
toolkit ports list --json before scaffolding any new service to detect available ports and avoid conflicts automatically.Environment State
Use
toolkit proxy list --json and toolkit autostart status --json to give your agent a full picture of the current dev environment before generating code.CI/CD Integration
1
Check for port conflicts before starting tests
At the beginning of your CI job, run a port conflict analysis to catch environment issues before your test suite starts:The JSON output includes a
conflicts array. If it is non-empty, your tests are likely to fail due to port collisions — fail fast here instead of debugging mysterious test failures later.2
Parse the JSON output and fail the build if conflicts exist
Use This pattern works in GitHub Actions, GitLab CI, CircleCI, Jenkins, or any shell-based pipeline.
jq (or any JSON parser in your CI environment) to assert that no conflicts exist before proceeding:3
Clean up proxy routes after the test run
After your tests complete, remove any proxy routes that were registered during the run to leave the environment clean for the next job:If you registered routes dynamically, parse the
toolkit proxy list --json output and remove every route whose subdomain matches your CI naming convention (e.g., prefixed with test-).Shell Scripting
The--json flag makes it easy to compose Toolkit with standard Unix tools. Here are a few practical shell snippets:
Kill the process on a specific port:
jq to extract just the port numbers in use: