Init & Projects

Two-Layer Setup Model

Tack runs as a machine-wide daemon with project-scoped execution.

• Explicit global setup lives in ~/.config/tack/config.yaml
• Repo-local overrides live in <repo>/.tack/config.yaml
• Each registered repo gets a stable .tack/project-id
• CLI commands resolve the current project from your working directory

tack setup is global and resumable. tack init is per-project and all-or-nothing.

Global Setup

Run global setup before initializing a project:

tack setup

Global setup records explicit selections for daemon service mode, daemon listen address, runtime, provider/auth binding, planner model, agent model, small-task model, sandbox provider, blueprint, and quality gates. It does not silently pick a provider, model, runtime, or workflow.

For scripted setup, use --non-interactive with required flags. Missing inputs are reported together:

tack setup --non-interactive \
  --daemon-service service \
  --daemon-listen 127.0.0.1:9800 \
  --runtime pi \
  --provider openai-codex \
  --auth-mode tack \
  --auth-method oauth \
  --credential-ref openai-codex \
  --planner-model <model> \
  --agent-model <model> \
  --small-task-model <model> \
  --sandbox-provider local \
  --blueprint standard \
  --quality-gate "go test ./..."

When Pi is selected and not installed, Tack can install it only after explicit consent with --install-pi and only when Bun or npm is available. Installing Node.js/npm is outside Tack's setup scope.

Project Init

Run tack init inside your repository:

cd your-project
tack init

What tack init Does

The init command creates project state from explicit project choices and global fallbacks:

1. Creates .tack/config.yaml — project-specific configuration
2. Agent runtime selection — project override or inherited global runtime
3. LLM provider selection — project override or inherited global provider
4. Authentication setup — API key or OAuth binding, stored in ~/.config/tack/credentials.yaml when Tack manages credentials
5. Sandbox provider selection — local (git worktrees) or Daytona (remote VMs)
6. Model selection — planner model, agent model, small-task model
7. Writes .tack/project-id — a stable UUID that the daemon uses to identify this project
8. Updates .gitignore — appends local runtime artifacts (.tack/project-id, .tack/*.db) while keeping config, blueprints, and rules committable
9. Registers with the daemon — registers the project before init succeeds

Every choice is validated before project files are kept. If validation or daemon registration fails, init removes partial .tack state created during the run.

Init summaries print effective values with source labels. Values inherited from global setup are shown as global fallbacks; project selections are shown as project overrides.

Daemon Service

The daemon reads the user config layer, not a per-project config file. Foreground mode remains available:

tack daemon

User service commands are available on supported macOS launchd and Linux systemd-user systems:

tack daemon install
tack daemon start
tack daemon stop
tack daemon restart
tack daemon status
tack daemon reload

tack daemon status reports provider, installed, enabled, running, healthy, listen address, config path, log path, and provider details.

Project Commands

You can manage registrations explicitly:

tack project add .                    # Register the current repo
tack project list                     # List all registered projects
tack project inspect                  # Show current project details
tack project relink <id> <new-path>   # Move an existing registration
tack project remove <id>              # Unregister a project

Most project-scoped commands resolve the current repo automatically from your working directory. If you need to target another repo:

tack plan "description" --project <project-id>
tack plan "description" --project /path/to/other/repo

Multiple Projects

The daemon supports multiple registered projects. Each project has its own:

• Config (.tack/config.yaml)
• Blueprints (.tack/blueprints/)
• Rules (.tack/rules/)
• Database (.tack/tack.db)
• Activity logs

When you run a CLI command, Tack resolves the project from your current working directory. This means you can have two repos registered and use Tack in both without switching contexts.

Auth Commands

You can also manage credentials directly:

tack auth add anthropic       # Add Anthropic API key
tack auth add openai-codex    # Add OpenAI Codex credential
tack auth add github          # Add GitHub PAT for GitHub PR workflows
tack auth add daytona         # Add Daytona API key
tack auth list                # Show all configured providers
tack auth test anthropic      # Check that a stored credential resolves

See the Credentials & Auth guide for full details on credential formats, multi-provider setup, and security.