Papa Tech Solutions

.cursorignore example

Context

Before you ask a question, search decides which files the agent is offered. A clone on another machine receives whatever Git is allowed to send.

The problem

Lockfiles, images, and build folders match a lot of searches. Secrets in an env file can be offered the same way. The other computer then downloads that weight too.

What you do

You block secrets and build output in .cursorignore and .gitignore. You leave lockfiles and images in the repo but out of search, so they open only when you name them.

What this achieves

The agent searches source. A shared copy of the project does not start by indexing generated files.

Who reads it

Cursor reads .cursorignore as files it should not index and should not open. .cursorindexingignore leaves a file in the repo and out of search, so the agent can still open it when you name it. .gitignore is what the other machine receives.

What it is for

A shared project wastes tokens when the agent searches lockfiles, generated images, and build folders for a one-line change. Ignore those paths.

Secrets belong in .gitignore and in .cursorignore. A sample env file can stay, so people still know which keys to set.

What goes in

Sample

.cursorignore

# Secrets
.env
.env.*
!.env.example

# Dependencies and build output
node_modules/
.next/
out/
dist/
build/
coverage/

# Logs and media the agent should never open
*.log
*.zip
*.mp4

# Add these only if the repo has them
# Pods/
# DerivedData/
# .gradle/

.cursorindexingignore

# In the repo, but out of search unless someone names the file
package-lock.json
yarn.lock
pnpm-lock.yaml
bun.lock
*.png
*.jpg
*.jpeg
*.webp
*.gif
*.pdf
*.map

# Keep a small logo searchable if you have one
# !public/logo.png

.gitignore (lines to add if missing)

.env
.env.*
!.env.example
node_modules/
.next/
out/
dist/
build/
coverage/
*.log

What stays out

Before launch, run the Vibe Coding Security Checklist. These files do not replace that audit. Open the Vibe Coding Security Checklist.