yt: Yandex Tracker CLI with safety policies
yt — Yandex Tracker CLI
A cross-platform NativeAOT Yandex Tracker CLI with four sign-in modes, a read-only mode, and queue and write-scope restrictions
High risk
We rate an entry high when the tool writes to external systems, handles money, production databases or secrets, or runs arbitrary commands. The CLI installs it only with your consent.
Why this level
- Write commands create, change, transition and delete issues, components and versions in the live Tracker
- The CLI's policies do not protect against direct edits to the config file or raw service-account credentials in the caller's environment
- Start with --read-only at login and allowed_queues set to the minimum needed, loosen only by deliberately recreating the profile
Install
Manual install
brew install RoboNET/yt/ytInstall on macOS Apple Silicon and Linux via Homebrew.
This is third-party code. Review the repository files before installing.
What it does
yt is a .NET NativeAOT binary weighing about 10 MB with no dependencies and no runtime, covering nearly the whole public Tracker API: issues, comments, worklogs, attachments, checklists, boards, sprints, projects, components, versions, fields and reference data. It supports four sign-in modes: OAuth via Yandex 360, an IAM token from Yandex Cloud, a service account, and a federated browser login with DPoP. Output format is JSON for agents or a table for people, chosen automatically by TTY. The key feature is a layered policy model inside the CLI itself: read_only fully blocks writes, allowed_queues restricts which queues can be read or written, allowed_write_issues allows writes only to specific issues, and external_effects blocks initiating notifications and automations. Policies can only be tightened via config set; loosening them requires recreating the profile.
Who it is for. For teams that need a Tracker CLI with genuinely strict, well-documented boundaries on what an agent or CI can do.
Good fit when
- You need to hard-limit an agent to a specific queue or even a single writable issue
- You work in Yandex Cloud and want a federated login like yc init
- A read_only guarantee matters as a technical request block, not just advice
Not a fit when
- A simple token with no queue or issue policies is enough: this model is richer than a one-off task needs
- You need the MCP protocol rather than a command-line binary
Example request
Show my open issues in the TECH queue and move TECH-146 to in progressLimitations
Policies only guard calls made through yt itself, not direct edits to the config file or raw service-account credentials in the caller's environment. The README explicitly calls this a second layer of defense, not the first. An IAM token lives for 12 hours; long-running work needs the Service Account or Federated mode. Boards, sprints, projects and global reference data are not filtered by allowed_queues.
How to disable. Run yt config set read_only true --profile name to temporarily block writes, or yt auth logout to forget the token.
Security check
- Write commands create, change, transition and delete issues, components and versions in the live Tracker
- The CLI's policies do not protect against direct edits to the config file or raw service-account credentials in the caller's environment
- Start with --read-only at login and allowed_queues set to the minimum needed, loosen only by deliberately recreating the profile
README in short
The Russian README describes the four authentication modes in detail, the full command list by group, the output format with automatic JSON or table detection, read_only mode, three independent policies (allowed_queues, allowed_write_issues, external_effects) with precise tables of allowed and blocked changes, the boundaries and honest limits of those policies, exit codes, and installing the AI-assistant skill via the Claude Code marketplace or universal installers.
FAQ
Can read_only be loosened after it is enabled?
Not via config set, that returns policy_violation; the only path is recreating the profile from scratch via auth login without the --read-only flag.
Are linked issues from other queues filtered out?
Keys and titles of linked issues show up in issue get, but those issues cannot themselves be read if they are outside allowed_queues.
Related
A self-hosted knowledge base with block-level references and a built-in MCP server for connecting AI agents to your notes
A CLI for every Google Workspace API with JSON output and agent skills: Drive, Gmail, Calendar, Sheets and more
Local search over Markdown notes, docs and meeting transcripts: keywords, semantic search and reranking, with an MCP server
A task manager for AI-driven development: breaks a PRD into dependent tasks and guides the agent through them via MCP or CLI