Control which files Bob can access by creating a `.bobignore` file in your project.

What is `.bobignore`?

Purpose: To protect sensitive information, prevent accidental changes to build artifacts or large assets, and generally define Bob's operational scope within your workspace.

How to use: Create a file named .bobignore in the directory of your workspace. List patterns in this file to tell Bob which files and directories to ignore.

Bob re-reads the .bobignore file automatically, so changes take effect within about 30 seconds without restarting. Bob can read the .bobignore file itself but cannot write to it, so Bob cannot change its own access rules.

Pattern syntax

The syntax for .bobignore is identical to .gitignore. Here are common examples:

Example	Description
`node_modules/`	Ignores the entire `node_modules` directory
`*.log`	Ignores all files ending in `.log`
`config/secrets.json`	Ignores a specific file
`!important.log`	An exception; Bob will not ignore this specific file, even if a broader pattern like `*.log` exists
`build/`	Ignores the `build` directory
`docs/*/.md`	Ignores all Markdown files in the `docs` directory and its subdirectories

To learn about syntax, refer to the official Git documentation on .gitignore.

How Bob tools interact with `.bobignore`

.bobignore rules are enforced across Bob's file tools:

Read and write tools

These tools check .bobignore before any file operation. If a file matches an ignored pattern, the operation is blocked:

read_file: Does not read ignored files.

write_file: Does not write to or create ignored files.

apply_diff: Does not apply diffs to ignored files.

insert_content: Does not insert content into ignored files.

search_and_replace: Does not modify ignored files.

GetSymbolsOverview: Does not parse ignored files for code symbols.

File discovery and listing

list_files tool: Ignored files are omitted from listings or marked with a 🔒 symbol (see "User experience" below).

Environment details: Workspace information provided to Bob, such as open tabs and project structure, is filtered to exclude or mark ignored items.

Command execution

execute_command tool: Bob checks whether a command from a predefined list (such as cat or grep) targets an ignored file. If so, the command is blocked. Commands outside this predefined list are not checked against .bobignore.

Restriction: .bobignore and the workspace sandbox setting ("Allow outside workspace tool requests") are two separate controls. .bobignore restricts which files Bob's file tools can access within the workspace. The workspace sandbox setting controls whether file tools can operate outside the workspace root. Neither control restricts execute_command for arbitrary shell operations; a shell command can still create, modify, or delete files anywhere the operating system permits, regardless of these settings.

Key limitations and scope

Workspace-centric: .bobignore rules apply only to files and directories within the current Bob workspace root. Files outside this scope are not affected.

execute_command scope: .bobignore enforcement for execute_command covers only a predefined list of file-reading commands. Arbitrary shell commands are not restricted by .bobignore or by the workspace sandbox setting.

Not a full sandbox: .bobignore controls Bob's file tool access within the workspace. It does not create a system-level sandbox and does not restrict shell command execution.

User experience and notifications

Visual cue (🔒): In file listings, files ignored by .bobignore may be marked with a lock symbol (🔒), depending on the showbobignoredFiles setting (defaults to true).

Error messages: If a tool operation is blocked, Bob receives an error:

"Access to [file_path] is blocked by the .bobignore file settings. You must try to continue in the task without using this file, or ask the user to update the .bobignore file."

Chat notifications: You will typically see a notification in the Bob chat interface when an action is blocked due to .bobignore.

This guide helps you understand the .bobignore feature, its capabilities, and its current limitations, so you can effectively manage Bob's interaction with your codebase.

Ignoring files