> For the complete documentation index, see [llms.txt](https://docs.tabnine.com/main/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tabnine.com/main/getting-started/tabnine-cli/git-integrations/github-actions/tabnine-cli-gha-trust-guidance.md).

# Tabnine CLI GHA Trust Guidance

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:

```shell
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](https://docs.github.com/en/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token) and [Limiting Credential Permissions](https://docs.github.com/en/actions/concepts/security/secrets#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](https://docs.github.com/en/actions/reference/security/secure-use).

### **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:***

```shell
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:***

```shell
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.

```shell
# 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](http://./tabnine-cli-admin-governance.md) for how MCP allowlists are enforced.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.tabnine.com/main/getting-started/tabnine-cli/git-integrations/github-actions/tabnine-cli-gha-trust-guidance.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.