How to Tell Which Tabnine Guidelines Are in Effect Right Now (2026 Guide)

Tabnine's file-based guidelines are the part that behaves like every other tool. They are Markdown files in a /.tabnine/guidelines/ directory, and that directory "will reside either 1) in your home directory or 2) on a per-project basis within your project directory." You can save multiple guideline files, and Tabnine's own framing is an analogy rather than a standard: "Think of these in a similar fashion to the agents.md file that other agentic tools use." Note that it is an analogy — the filename is not AGENTS.md, and a repository carrying one does not automatically feed Tabnine. There is also a size recommendation: "It is recommended to keep your guidelines.md file to 500 lines or less."

Three things sit outside that directory, and each breaks the assumption that reading files answers the question.

The Admin Console outranks your file. This is the sentence to internalize:

"Guidelines that are input here will have the same effect as guidelines listed in your guidelines.md file, but they will take precedence over personal guidelines that exist in the guidelines.md file."

Organization guidelines are "applicable to all your organization's users and projects." So the authoritative layer is one you may not be able to read, and it wins against the file in front of you. If your local guideline says one thing and the console says another, the console's version is what the agent follows — and nothing in your repository records that.

There is a propagation window. Console changes "will be applied in the IDE extension after 15 minutes, or upon restarting the IDE or the extension." For up to a quarter of an hour after an admin edits a guideline, your session is running the previous version. During that window the effective set matches neither your file nor the current console state. This is the most reproducible way to get two engineers, both correctly configured, to see different agent behaviour on the same commit.

The CLI uses two separate delivery paths, and only one has a switch. Tabnine's CLI documentation opens by warning that "agent guidelines are managed differently in Tabnine CLI than they are for the Tabnine IDE plugin," then describes two flows.

The first: "organization instructions and service-account instructions are added to the agent's operating context. These instructions are configured outside the CLI by your Tabnine administrator. When Tabnine CLI starts, it fetches the available instructions for your authenticated account and applies them to the session." Service-account instructions "only apply when they are configured for the authenticated service account."

The second: coding guidelines "available through the built-in Tabnine Coaching Guidelines tool," which the agent can query "before it writes code, reviews code, or answers questions about your team's standards."

And the line that matters most for our question:

"These flows are separate. Organization and service-account instructions are fetched automatically from your Tabnine account context. The Coaching Guidelines setting controls only the built-in Coaching Guidelines MCP server."

So the one setting you can see and toggle — enableCoaching, reachable through the /settings dialog — governs one of the two paths. The documentation is explicit that "this setting doesn't control whether organization or service-account instructions are fetched and added to the session context." Turning it off does not give you a guideline-free session; it gives you a session with one path closed and the other still open.

Failures are silent by design. Both fallbacks degrade quietly: "If Tabnine CLI cannot fetch organization or service-account instructions, the session continues without them. If Coaching Guidelines are not supported by your Tabnine server, the built-in Coaching Guidelines tool is not loaded."

Nothing errors. A network hiccup, an expired session, a server that does not support the feature — the agent keeps working with a smaller instruction set and no signal. That is the same failure shape we described in why agents ignore your instruction files, except here the file is fine and the fetch is what failed.

One clarification, because "guidelines" is doing a lot of work in Tabnine's vocabulary: none of the above is Tabnine's memory story. Tabnine documents Personalization, Connection for global codebase awareness, and an admin-side Context Engine with assets, data sources, runs, analyzers, and coaching guidelines. Those are separate mechanisms with their own configuration; this guide is only about the guideline layer that shapes agent behaviour in a session.

Reading guidelines.md and moving on. Answers the wrong question. The file tells you what you asked for, not what is applied — and the console layer explicitly takes precedence over it.

Asking the agent what its instructions are. Better than nothing, and Tabnine endorses a narrow version of it: "You can also ask Tabnine CLI whether the Coaching Guidelines tool appears to be available in the current session." But read the qualifier the docs attach — "this is a practical check, not a standalone status command." It tells you whether a tool looks available, not which guideline text is in context, and it says nothing about the organization-instruction path.

Restarting whenever something looks wrong. Effective and unfalsifiable. A restart applies console changes immediately instead of waiting out the fifteen minutes, and a setting change requires one anyway — "changing this setting requires restarting Tabnine CLI." But if a restart fixes it, you have learned that you were stale, not what you were stale about.

Asking your admin to read the console to you. Correct source, wrong cadence — it answers the question once, for one person, and the console can change again without notice.

Duplicating the console guidelines into a local file. Tempting, and it makes the conflict worse. Now you have two copies with a documented precedence order between them, and when the console version changes, your local copy becomes a confidently wrong record. Two records that can disagree with no reconciliation is the situation we mapped in detecting memory conflicts.

You cannot query the effective set. You can enumerate its inputs, detect each one by behaviour, and keep a written expectation to compare against.

Step 1: Enumerate all five inputs, per surface

Write down, for this project and this machine, what exists at each of these:

The project directory's .tabnine/guidelines/ — every file, not just guidelines.md, since multiple files are supported. Your home directory's .tabnine/guidelines/ — the same, and note that these apply across all your projects. The Admin Console's General Guideline, as reported by whoever can see it, with the date it was last changed. Service-account instructions, if the session authenticates as a service account rather than as you. And the Coaching Guidelines tool's state, from /settings.

Then note which surface you are asking about. The console layer reaches both — "guidelines configured in the Admin Console apply to CLI sessions in the same way they apply to IDE chat sessions. No additional configuration is required on the CLI side" — but the CLI's two-flow model and the IDE's fifteen-minute propagation are surface-specific. The same repository can behave differently in the terminal and the editor, correctly.

Step 2: Detect each input by contradiction

Since Tabnine describes the available check as "a practical check, not a standalone status command," test each source instead with an instruction that is unmistakable and harmless — a naming convention you never otherwise use, or a required comment header on new functions.

Test your project file first: add the marker, restart to skip the propagation question, and ask for a small function. If the marker appears, the project directory is loading.

Test the console layer next, by having your admin add a different marker while your project file keeps its own. Whichever appears tells you which layer won — and Tabnine's documented answer is the console. Confirming it in your own environment is worth the ten minutes, because it is the fact that most often contradicts people's mental model.

Test the propagation window once, deliberately: have the admin change the console marker and note when it appears without a restart. Knowing the window is real turns the next disagreement into a diagnosis.

Test the CLI's Coaching Guidelines path by asking the agent for a guideline-based review. Tabnine's documented behaviour is that "if you ask for guideline-based review and no guidelines are available, Tabnine CLI should tell you that it cannot access configured guidelines instead of inventing rules." An honest refusal is a useful signal. Silence with plausible output is the case to watch for.

Step 3: Keep a written expectation, versioned outside the tool

The tests above give you a snapshot. The thing that makes the snapshot useful next month is a record of what the answer should be.

That record needs three properties. It has to live outside the console, because the console is the layer you cannot read from a session. It has to live outside .tabnine/guidelines/, because a duplicate of the authoritative text becomes a wrong record the moment the console changes. And it has to be readable by every surface, because the CLI and the IDE assemble their sets differently.

What goes in it is not the guideline text. It is the metadata around it: which rule is expected to be enforced at the organization level and which is personal, who decided, when, and what it replaced. Then "which guidelines are in effect" becomes a comparison between a written expectation and an observed behaviour, rather than a guess. The general case for keeping that kind of record under version discipline is in treating AI memory like Git.

MemoryLake is where that expectation lives: the decision record behind each guideline, independent of which layer currently delivers it. When the console changes, you have something to compare the change against. When a guideline disappears, you know what it said and why it was there. Get started here.

Step 1: Create an API key

Create a workspace for the team, not for one repository — organization guidelines apply "to all your organization's users and projects," so the record should be at least as broad as the layer it describes.

Step 2: Upload your first memories

Record the results of your Step 2 tests: which layer won, and on which surface. Then add the decision behind each guideline currently in the console — the reason, the date, and the version it replaced. Ask your admin for that history once; it is much harder to reconstruct later than to capture now.

Step 3: Connect your AI & agents

Connect both Tabnine surfaces you use, the IDE plugin and the CLI. Because the two assemble guidelines differently, having them read one shared decision record is the only way a rule's reason is available identically in both, even when the guideline text arrives by different paths.

Disagreements between two engineers become diagnosable. When one person's agent follows a convention and another's does not, you have a checklist: propagation window, surface difference, service-account authentication, or a fetch that failed silently. That is four hypotheses instead of a shrug.

Silent degradation becomes detectable. Because the documented fallback is that "the session continues without them," the only way to notice is to have an expectation to compare against. A marker test takes a minute and is the difference between finding out today and finding out at review time.

Admin changes stop being invisible events. A console edit currently reaches your team as a behaviour change with no announcement. A written record with dates turns it into something you can point at.

And the reasoning survives a change of layer. Guidelines move — from personal file to console, from console to service account — and each move rewrites the text. The decision behind it does not have to move at all. This is the practical form of the ownership question we raised in whether AI memory is a feature or lock-in.

Restart rather than wait, when you are testing. The fifteen-minute window is a fine default for normal work and an obstacle to diagnosis. Restarting the IDE or the extension applies console changes immediately.

Keep personal and organization guidelines about different things. Since the console takes precedence over your guidelines.md, any overlap is a conflict you will lose. Use the local file for genuinely personal preferences and leave shared standards to the layer that is designed to enforce them.

Do not treat enableCoaching as a global off switch. It "controls only the built-in Coaching Guidelines MCP server," and organization and service-account instructions are fetched regardless. If you need a genuinely clean session for testing, that is an authentication question, not a settings question.

Check which identity the session is using. Service-account instructions "only apply when they are configured for the authenticated service account," so a CI run and a local session can legitimately have different guidelines. Note the identity alongside the surface in your records.

Respect the length recommendation. Tabnine suggests keeping guidelines.md to 500 lines or less. Multiple guideline files are supported, so split by topic rather than growing one file past the recommendation.

Audit on a schedule, not on suspicion. Once a quarter, run the marker tests and compare the result to your written expectation. The broader version of that habit is in auditing what your AI actually remembers, and it matters more here because the authoritative layer is not one you can inspect from a session.

Tabnine's guideline system is more capable than a single instruction file — organization-wide enforcement, service-account scoping, and a tool the agent can query mid-task are all things a flat file cannot do. The cost of that capability is that the effective set is assembled at session start from sources with different owners, different surfaces, and one documented delay.

There is no command that prints the answer, and Tabnine says so. What you can do is enumerate the five inputs, test each by contradiction, and keep a written record of what should be in effect. Then the question stops being unanswerable and becomes a comparison — which is all "which guidelines are in effect right now" ever needed to be.

If you are still evaluating the move, migrating from GitHub Copilot to Tabnine covers how the precedence direction inverts between the two, which is the single most surprising part of arriving here.