1.1.7 bazel info
bazel info is the command you reach for when you no longer want to infer Bazel's filesystem layout from log lines, symlinks, or guesswork. It asks the current Bazel instance for concrete paths and runtime metadata: where the workspace root is, which output_base identifies the active server, where actions see their files, and where the current configuration writes binaries or test logs1,2,3.
Ask Bazel For One Key
Running plain bazel info prints a long key-value listing. In day-to-day work, the more useful form is bazel info <key>, which prints only one value and is especially convenient in scripts1.
bazel info workspace
bazel info output_base
bazel info bazel-bin
That small habit pays off quickly. When a path matters, ask Bazel instead of assuming that bazel-bin exists as a symlink in the workspace, or that all state lives in one obvious cache directory on disk1,2.
Keep Three Roots Separate
Most path confusion comes from collapsing three different roots into one.
workspace is the absolute path to the base workspace directory1. It is the quickest sanity check that Bazel recognized the repository boundary correctly.
output_base is the per-user, per-workspace state root1. Bazel places scratch data and build output below it, and the client/server architecture uses it to decide which long-lived server process a bazel invocation should talk to1,3. If two invocations use different output bases, they are talking to different servers, even in the same repository. That is the concrete operator-facing side of 1.1.3 Server/Client Architecture.
execution_root sits underneath output_base and is the root of the files visible to commands executed during the build1,2,4. In non-sandboxed local execution it is the working directory for those commands4. If the workspace directory is writable, Bazel also places a bazel-<workspace> symlink at the repo root pointing here1.
output_base is the whole Bazel state tree, execution_root is the action-visible working tree inside it, and bazel-out is the output subtree under that execution root. 0.1.4 Output Root introduced the visible symlinks. bazel info gives you the real paths behind them1,2.
Convenience Paths Follow The Current Configuration
The most practical info keys are usually bazel-bin and bazel-testlogs, because they answer "where did Bazel put the thing I want to inspect?"1 But they are configuration-specific, not universal constants.
There is an important subtlety here: bazel info accepts the same analysis-affecting options that change output directories, such as --cpu or --compilation_mode1. That means these two commands can legitimately point at different directories:
bazel info -c dbg bazel-bin
bazel info -c opt bazel-bin
This is why scripts should prefer bazel info bazel-bin over assuming the workspace symlink exists or hard-coding a path under bazel-out/1. The workspace-level bazel-bin, bazel-testlogs, and bazel-out names are convenience symlinks only. Bazel itself does not rely on them, and it creates them only when the workspace root is writable1,2.
If you need the broader directory rather than the convenience leaf, output_path points at the actual bazel-out directory under the execution root1. That is often the missing link when bazel-bin is too narrow but output_base is too broad.
Useful Diagnostic Keys Beyond Paths
A few non-path keys also belong in the normal debugging toolkit.
server_pid tells you which Bazel server process is currently serving the workspace, and server_log gives you the path to its long-lived debug log1. When the deeper server model in 1.1.4 Inspecting Server State becomes relevant, these are the first handles you use from the CLI.
release prints the exact Bazel release string for the current instance1. That matters when a path, flag, or behavior differs between versions and you want to confirm which binary you are talking to.
install_base points to the directory where Bazel unpacked tools delivered with the Bazel binary itself4. Most users do not need to inspect it daily, but it is useful when separating "state for this workspace" (output_base) from "files tied to this Bazel installation" (install_base).
command_log points at the interleaved stdout/stderr log of the most recent Bazel command1,5. There is one easy mistake: running bazel info itself makes info the most recent command, so it overwrites the command log contents you may have wanted to inspect. The location stays stable unless the output base changes, but the contents do not1,5.
bazel info is a locator, not a full debugger. It locates state and identifies the Bazel instance you are interrogating. To interpret that state, move outward: 1.1.3 Server/Client Architecture for server identity, 1.1.4 Inspecting Server State for the warm in-memory state, 2.4.2 Where Bazel Caches Things for the cache layers, and 1.1.6 bazel clean for what happens when you delete parts of it.
Use bazel info whenever the question is "where is it?" or "which Bazel instance am I talking to?" workspace tells you the repo root, output_base identifies the full state tree and server, execution_root shows the action-visible working tree, and bazel-bin / bazel-testlogs point to the current configuration's output directories.
Check your understanding · 2 questions
1.Match each bazel info key to the path it reports:
Drag each answer onto the matching prompt, or click an answer and then click a prompt
2.Why should scripts prefer bazel info bazel-bin over assuming ./bazel-bin exists?
Select one answer
Footnotes
-
Commands and Options —
bazel info <key>, configuration-independent vs configuration-specific keys,output_path,server_pid,server_log,command_log, and reliable use ofbazel-bin↩1 ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 -
Output Directory Layout — workspace symlinks as convenience only,
output_baselayout,execroot, and wherebazel-out,bin, andtestlogssit ↩1 ↩2 ↩3 ↩4 ↩5 -
Client/server implementation — output base as server identity and why different output bases mean different Bazel server processes ↩1 ↩2
-
Bazel Glossary — precise definitions of
execution_rootandinstall_base, including their relatedbazel infokeys ↩1 ↩2 ↩3 -
Calling Bazel from scripts —
command_loglookup and the caveat thatbazel infooverwrites the most recent command log contents ↩1 ↩2
