CLI Reference

Synopsis

logic64 <command> [options]

Every command supports --help for inline usage text. Global flags (--api-url, --api-key) can be passed to any command to override the stored config for that invocation.

Global flags

These flags apply to every command. When --api-url and --api-key are omitted, the CLI reads from the values stored by logic64 auth or from environment variables.

logic64 auth

Authenticate the CLI with your Logic64 API key. Credentials are stored locally in ~/.logic64/config.json and reused by all subsequent commands. Run this once per machine.

$ logic64 auth --api-key l64_YOUR_API_KEY --api-url https://api.logic64.com
# ✓ Authenticated. Credentials stored in ~/.logic64/config.json

• The key and URL are written to ~/.logic64/config.json. Delete this file to de-authenticate.
• Credentials can also be supplied via environment variables instead of running auth — see Environment variables.
• The stored API key is used for all HTTP requests to the backend. Never commit it to version control.

logic64 pull <bundle-id>

Download and apply a bundle to the current directory. The CLI reads manifest.json inside the bundle ZIP and routes each file to its declared destination. Global config files are backed up before any change. A resolution_log.json is written to the project root recording every file written, every config merge, and every conflict resolved.

$ logic64 pull a3f2bc89-4d1e-47a0-b8c6-2e5f91340abc
# ↓ Downloading bundle a3f2bc89…
# ✓ 23 files written — CLAUDE.md, memory.md, .env, MCP configs
# ✓ MCP server merged into ~/.config/claude-code/config.json
# ✓ resolution_log.json written to project root
# ✓ Bundle confirmed (ACK)

Execution order within a single pull:

• Download the bundle ZIP from /bundles/:id/download.
• Validate manifest.json — reject if missing or schema-invalid.
• For each global config file to be modified, write a .logic64.backup copy in the same directory before touching the file.
• Route and write each file according to its destination_type and merge_strategy. Port conflicts are auto-resolved by incrementing (max 10 attempts); all resolutions are logged.
• Write resolution_log.json to the project root.
• Send ACK — POST /bundles/:id/ack. Retried up to 3 times with 0 ms / 500 ms / 2 000 ms backoff. If all 3 attempts fail, a .logic64.ack-pending sentinel file is written to the project root. The backend's 24-hour cleanup cron provides the safety net.

Exit conditions: exits 0 after a successful ACK (or after writing the sentinel). Exits 1 if the bundle is not found or the manifest is invalid. Exits 2 on network failure during download.

logic64 rollback <bundle-id>

Undo a previously applied bundle. The CLI reads the resolution_log.json for the specified bundle ID and reverses every change Logic64 made.

$ logic64 rollback a3f2bc89-4d1e-47a0-b8c6-2e5f91340abc
# ✓ Restored ~/.config/claude-code/config.json from backup
# ✓ Deleted 23 files from project root
# ✓ rollback_log.json written

• Reads resolution_log.json (must be present in the project root).
• For each global_config_backup entry: copies {filename}.logic64.backup back over the current file, restoring the pre-pull state.
• For each file written to the project root: deletes it. Files in the project root are considered recoverable via version control.
• Writes rollback_log.json to the project root, recording every file restored or deleted.
• Does not perform any git operations. No commits, no resets.
• Only affects files Logic64 wrote or modified — other files in your project are untouched.

logic64 status <bundle-id>

Query the current state of a bundle from the Logic64 backend. Useful for confirming whether a bundle is ready to pull, already downloaded, or expired.

$ logic64 status a3f2bc89-4d1e-47a0-b8c6-2e5f91340abc
# bundle_id:    a3f2bc89-4d1e-47a0-b8c6-2e5f91340abc
# status:       pending_download
# file_count:   23
# created_at:   2026-05-15T10:30:00Z

• pending_download — bundle is ready. Run logic64 pull <bundle-id>.
• downloaded — bundle was already pulled and ACKed. Use logic64 export to get a fresh copy.
• expired — bundle exceeded the 24-hour window without an ACK and has been cleaned up.

logic64 export <projectId>

Re-emit a fresh bundle from a persisted project without running the generation engine. The bundle is assembled deterministically from your project's saved files and architecture state. No inference is performed — this is a pure repackage. Use this when you need to pull the same project onto a second machine, or after a bundle has already been downloaded and ACKed.

$ logic64 export proj_7f3a1e
# ✓ New bundle created: b9c12d44-7e2f-48b1-a903-3d7f52109abc
# → Run: logic64 pull b9c12d44-7e2f-48b1-a903-3d7f52109abc

• Calls POST /projects/:projectId/bundles/repackage on the backend.
• No inference is involved — the bundle is assembled from files already persisted on the server.
• Rate-limited to 3 requests per minute per user.
• Prints the new bundle ID and the ready-to-run logic64 pull command.
• Exits 1 if the project has no persisted files yet — run a generation first from Logic64 Studio.

Exit codes

The CLI uses conventional exit codes. Scripts that wrap logic64 can inspect $? to branch on success or failure.

Environment variables

Environment variables provide an alternative to running logic64 auth. They are useful in CI pipelines or containerized environments where writing to ~/.logic64/config.json is not practical. When both a stored credential and an environment variable are present, the environment variable takes precedence.

# Set once in your shell profile or CI secret store
export LOGIC64_API_URL=https://api.logic64.com
export LOGIC64_TOKEN=l64_YOUR_API_KEY
# All subsequent commands pick up the env vars automatically
$ logic64 pull a3f2bc89-4d1e-47a0-b8c6-2e5f91340abc

Next steps

Explore what Logic64 writes to your project, integrate via the REST API, or browse your saved projects in the library.