Install via Homebrew (macOS)

brew tap tiylabs/tap
brew install --cask tiycode

To upgrade later:

brew upgrade tiycode

Build from Source

Prerequisites

Before running the app, make sure your environment has the toolchain needed for a Tauri 2 project:

• Node.js and npm
• Rust toolchain
• Platform dependencies required by Tauri

Run in development

npm install
npm run dev

Run the web UI only

npm install
npm run dev:web

Build

npm run build

Type-check the frontend

npm run typecheck

Run Rust tests

cargo test --manifest-path src-tauri/Cargo.toml

Shell Environment Setup

TiyCode's built-in agent shell may launch as a non-interactive, non-login shell. In this mode, only minimal system paths (e.g. /usr/bin:/bin) are available. Tools installed via version managers — such as node, npm, bun, cargo, or go — will not be found unless you configure your shell startup files correctly.

Quick Start

~/.zprofile — examples

eval "$(/opt/homebrew/bin/brew shellenv)" # Homebrew (macOS) export NVM_DIR="$HOME/.nvm" # nvm (Node.js) [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" export BUN_INSTALL="$HOME/.bun" # Bun export PATH="$BUN_INSTALL/bin:$PATH" . "$HOME/.local/bin/env" # Rust / Cargo export PATH="/usr/local/go/bin:$PATH" # Go

</details>

<details>
<summary><strong>Linux (Bash)</strong></summary>

1. Keep environment variables in `~/.bash_profile` (or `~/.profile`).
2. Set `BASH_ENV` to point to a file that sources your profile:

How Shell Config Files Are Loaded

Different shell invocation modes load different config files. The table below shows which files are sourced in each mode:

Zsh (macOS default / Linux)

Bash (Linux default)

_{¹ Most distros source ~/.bashrc from ~/.bash_profile, so in practice it runs for login shells too.}

TiyCode's agent shell falls into the non-interactive column — only ~/.zshenv (zsh) or $BASH_ENV (bash) is guaranteed to load.

Fix: Ensure Environment Variables Load for All Shell Modes

<details> <summary><strong>macOS / Linux (Zsh)</strong></summary>

1. Move all export statements and PATH modifications from ~/.zshrc into ~/.zprofile. Keep interactive-only settings (aliases, completions, oh-my-zsh, themes, prompt) in ~/.zshrc.

1. Source ~/.zprofile from ~/.zshenv so that non-interactive shells also get the environment:

```bash

~/.zshenv

if [ -z "$__ZPROFILE_LOADED" ] && [ -f "$HOME/.zprofile" ]; then export __ZPROFILE_LOADED=1 source "$HOME/.zprofile" fi

The `__ZPROFILE_LOADED` guard prevents double-loading in login + interactive shells.

Common items to move into `~/.zprofile`:

~/.bash_env — new file

if [ -z "$__BASH_PROFILE_LOADED" ] && [ -f "$HOME/.bash_profile" ]; then export __BASH_PROFILE_LOADED=1 source "$HOME/.bash_profile" fi

</details>

<details>
<summary><strong>Windows (PowerShell)</strong></summary>

On Windows, TiyCode typically inherits the system and user environment variables set via **System Settings > Environment Variables**. If you installed Node.js, Rust, or other tools via their official installers, they should already be on PATH.

If you use a version manager like **nvm-windows**, **fnm**, or **volta**, make sure the shim directory is added to your **User PATH** in system environment variables — not only in a PowerShell profile.

To verify your current PATH in PowerShell:

</details>

Verify After Configuration

After updating your shell config files, restart TiyCode (a full quit + relaunch, not just a new thread) and ask the agent to run:

echo $PATH
which <your-tool>   # e.g. node, cargo, go, bun, python ...

If the output includes the expected paths and the tool is found, your environment is correctly configured.

Continuous Integration

Pull requests to master run GitHub Actions checks for commit message format, frontend type-checking, Vitest unit tests, web asset builds, Rust formatting, and locked Rust tests. An optional PR review workflow can run TiyAgents/code-review-agent-action when the required LLM secrets and variables are configured.

Extensions Model

TiyCode treats extensibility as a first-class part of the desktop workbench.

• Plugins provide locally installed extension packages with hooks, tools, commands, and skill packs.
• MCP is modeled as its own extension category and managed by the Rust host, including user/workspace scoped configuration.
• Skills act as reusable agent capability assets and are indexed from builtin, workspace, or plugin sources.
• Provider catalogs are bundled as snapshots and can be normalized or refreshed so model capabilities stay aligned with runtime behavior.

These capabilities are surfaced through the Extensions Center, while runtime access is still governed by the host through tool gateways, policy checks, approvals, and audit boundaries.

Troubleshooting & Debugging

When something goes wrong — model requests not being sent, responses not arriving, or behavior not matching expectations — you can use the RUST_LOG environment variable to control log verbosity on the Rust / tiycore side.