Tabnine CLI GHA Trust Guidance

This guide outlines security configurations and best practices for integrating Tabnine CLI with GitHub Actions (GHA) workflows.

This guide outlines security configurations and best practices for integrating Tabnine CLI with GitHub Actions (GHA) workflows. When running Tabnine CLI in CI, you must determine whether your workflow operates on trusted or untrusted data.

1. Determine If Your Workflow Processes Untrusted Data

Data Trust Level	Required Configuration
Fully Trusted Data — inputs from repo owners or high-trust collaborators	Use --approval-mode yolo or --yolo in your workflow
Untrusted Data — GitHub issues or pull requests from non-collaborators	Follow the hardening guidelines in Sections 2 and 3, then apply tool allowlisting

2. Workspace Trust in CI

Tabnine CLI requires the current workspace to be trusted before it will execute. In non-interactive (headless) CI environments, use one of the following approaches.

TABNINE_CLI_TRUST_WORKSPACE

Set this environment variable to bypass the interactive trust prompt:

env:
  TABNINE_CLI_TRUST_WORKSPACE: true

Alternatively, pass the --skip-trust flag, which sets the same variable for the session:

tabnine --skip-trust --approval-mode plan --prompt "Summarize the changes in this pull request."

3. Permissions and Principle of Least Privilege

Grant only the minimum privileges necessary for the workflow to complete its task.

Set a minimal set of GitHub token permissions. Even permissions that appear downscoped can pose a security risk (e.g., actions: write). See GitHub's Modifying GitHub Tokens for Least Privilege and Limiting Credential Permissions.

Prefer workflows where a maintainer manually triggers the PR review rather than triggering automatically on forks. This prevents untrusted content from being processed without human oversight.

See GitHub's GHA Best Practices for Security.

4. Tool and Command Allowlisting

If your workflow processes untrusted data, strictly limit which tools Tabnine CLI is allowed to execute. Prefer a minimal, read-only set of tools and allowlist additional commands only if necessary.

Example — Read-only workflow with tool allowlisting:

tabnine --approval-mode plan 
  --allowed-tools read_file list_directory grep_search 
  --prompt "Summarize the changes in this pull request."

Example — Trusted workflow using YOLO mode:

tabnine --yolo 
  --prompt "Review this code and apply formatting fixes."

5. Approval Modes in CI

Tabnine CLI provides four approval modes relevant to CI usage. Select the mode that matches the trust level of your workflow's data source.

Mode	Flag	Behavior
default	(none)	Prompts the user for each tool call. Not suitable for headless CI.
plan	--approval-mode plan	Read-only; no tool execution. Safe for untrusted data analysis.
auto_edit	--approval-mode auto_edit	Auto-approves file edit tools only.
yolo	--yolo or --approval-mode yolo	Auto-approves all tool calls. Use only for fully trusted workflows.

Note that --yolo and --approval-mode are mutually exclusive; if both are passed, the CLI returns an error instructing you to use --approval-mode=yolo instead.

In non-interactive (headless) mode, any tool decision that would normally prompt the user (ASK_USER) is automatically converted to DENY. Pairing plan mode with --allowed-tools provides the strongest safety posture for untrusted data.

6. MCP Servers in CI

If your workflow uses MCP servers, ensure that the organization's admin allowlist is configured before running Tabnine CLI in CI. Locally configured MCP servers not present in the admin allowlist are ignored at runtime. In untrusted workflows, disable MCP entirely by not passing --allowed-mcp-server-names, or restrict to specific trusted servers.

# Restrict to a single trusted internal MCP server
tabnine --approval-mode plan 
  --allowed-mcp-server-names internal-corp-tool 
  --prompt "Analyze the diff for security issues."

See Enterprise Admin Controls for how MCP allowlists are enforced.