Set up the CLI

The tiden CLI is the recommended way to connect repositories, CI, agents, and local automation to Tiden.

Install

macOS with Homebrew:

brew install --cask qase-tms/tap/tiden

Linux or macOS without Homebrew:

curl -fsSL https://tiden.ai/install.sh | bash

Windows PowerShell:

irm https://tiden.ai/install.ps1 | iex

Verify:

tiden version

Authorize with browser setup

Run:

tiden setup

The setup flow:

Creates a setup session.
Opens the Tiden app in your browser.
Lets you approve the CLI.
Stores the login in ~/.tiden/config.json, one entry per workspace of the account.
Selects the workspace, and asks only when several are possible. The choice is written to the repository's .tiden/config.json.
Can bind the current repository to a product and install intent hooks.

Validate the token:

tiden config verify

tiden auth login

This opens the browser for the same device-flow login as tiden setup. Use --no-browser to print the URL and code instead of opening a browser. For headless environments, pass --api-token <token> or set TIDEN_API_TOKEN. On a self-hosted Tiden the login uses the base URL of your stored logins; pass --base-url <url> to sign in somewhere else. If your stored logins point at several servers, the command asks for --base-url instead of guessing.

Login stores the new token for every workspace the account can see: a workspace that already has an entry in ~/.tiden/config.json gets the new token (this is how you rotate a token or replace an old account), and a workspace without an entry is added. It never changes which workspace the current repository is bound to — only tiden setup does that. It prints the account and one line per workspace, updated or added.

Sign out

tiden auth logout

Run with no flags in a terminal, it lists the logged-in workspaces as a numbered list and asks which one to log out of (Enter cancels). For scripts, select without asking:

tiden auth logout --workspace-id <id>
tiden auth logout --account <email>
tiden auth logout --all

Logout only removes stored credentials from ~/.tiden/config.json. It never calls the server, so the token stays valid until you revoke it: an account token in Settings > API tokens, a product token in Product settings > API tokens. The repository binding stays as is. If the current repository is bound to the workspace you logged out of, the next command reports that no logged-in account is a member — run tiden auth login to fix it.

Manual configuration

Use manual configuration for CI or locked-down environments. In CI, use a product token from Product settings > API tokens. Store one with Full access to this product as shown below. Pass a publish-only token through TIDEN_API_TOKEN and never store it; see Use a publish-only token.

tiden config set baseUrl https://app.tiden.ai
printf '%s' "$TIDEN_API_TOKEN" | tiden config set apiToken -
tiden config verify

Add --workspace-id <id> to config set apiToken and config set baseUrl when more than one workspace login is already stored. For headless setup, prefer:

tiden setup --api-token "$TIDEN_API_TOKEN" --workspace-id <workspace-id> --yes

The CLI resolves configuration in this order:

~/.tiden/config.json (one entry per workspace)
Environment variables: TIDEN_BASE_URL, TIDEN_API_TOKEN, TIDEN_WORKSPACE_ID, TIDEN_TIMEOUT
CLI flags: --base-url, --api-token, --workspace-id, --timeout

Bind a repository to a product

From the repository root:

tiden product bind --product-id <product-id>

Binding writes local product metadata so intent capture and other repo-aware commands can resolve the product without repeated flags.

Output format

--format adapts to where the output is going. Run a command yourself at a terminal and you get styled, human-readable text:

tiden product list --workspace-id <workspace-id>

Pipe or redirect the same command — a script, a CI job, an AI coding agent — and you get json instead, unchanged from every earlier release:

tiden product list --workspace-id <workspace-id> > products.json

Pin --format json whenever something parses the output. It is the stability promise, and it does not depend on how the command happens to be launched — some agent harnesses run shell commands under a pseudo-terminal, which looks like an interactive terminal to tiden:

tiden product list --workspace-id <workspace-id> --format json

--format text forces the human rendering the same way. See Tiden CLI for the full precedence rules and the environment variables that override them.

Install intent hooks

After binding a repository:

tiden intent install
tiden intent status --format text

This wires Tiden-managed hooks for supported coding agents and a git fallback hook. See Configure agents for the full intent capture workflow.

Allow tiden in Claude Code

The intent hooks ask the coding agent to run tiden intent commands. In Claude Code auto mode, a classifier approves each Bash command. It can deny a tiden command, and a denied command breaks the intent loop. Claude Code's permission rules let these commands run without the classifier.

tiden setup offers to add these rules right after the Codex sandbox step. It offers them only when Claude Code is installed (~/.claude exists) and the Claude Code hooks are wired. The rules go into permissions.allow in ~/.claude/settings.json, the same file as the hooks.

An interactive run asks. The default is Yes.
--yes counts as consent.
Without a terminal and without --yes, setup writes nothing. It prints the JSON block for you to paste.
--skip-claude-permissions skips the step.

For a headless machine, tiden setup --yes writes the rules. The rules have this shape:

{
  "permissions": {
    "allow": [
      "Bash(tiden intent:*)",
      "Bash(tiden doctor:*)",
      "Bash(tiden spec get:*)",
      "Bash(tiden run list:*)"
    ]
  }
}

Bash(tiden intent:*) covers the whole tiden intent group. Four rules cover the writes the hooks name: tiden test push, tiden run create, tiden run report and tiden run complete. The other rules cover read-only commands. tiden permissions status prints the full list.

Some commands are not allowed on purpose:

tiden run exec runs any child command, so an allow rule would allow that command too.
tiden setup, tiden auth, tiden config set, tiden skill, tiden upgrade and tiden permissions change your setup.
Writes that only the skills drive, such as tiden spec push, tiden branch merge and tiden test ingest, keep a prompt.

tiden only appends rules that are missing. It never removes or reorders your own rules. It never edits deny or ask. A deny rule beats an allow rule in every scope. If a deny or ask rule shadows a tiden rule, for example Bash(tiden:*) in deny, setup names it. So do tiden doctor and tiden permissions status.

tiden doctor shows a Claude Code permissions row. It warns when rules are missing. To fix it, run tiden setup or tiden permissions install.

To manage the rules later:

tiden permissions status
tiden permissions install --yes
tiden permissions uninstall

tiden permissions uninstall and tiden intent uninstall remove only the rules tiden added, and the record of them. tiden keeps that record in ~/.tiden/agent-permissions.json. tiden upgrade adds rules that are new in a release only if you agreed before. It never asks.

If you answered No in setup, that answer sticks, also for tiden setup --yes. tiden permissions install adds the rules when you change your mind.

Claude Code checks each part of a piped or chained command on its own. cd, cat, head, grep and read-only git are read-only built-ins, so cd repo && tiden intent status runs without a prompt. In tiden doctor; rm -rf build, the rm part still needs approval.

Codex is not covered here. Its network access is the separate Codex sandbox step.

Install​

Authorize with browser setup​

Sign in again or add another account​

Sign out​

Manual configuration​

Bind a repository to a product​

Output format​

Install intent hooks​

Allow tiden in Claude Code​