Cursor sets `CI=1` in recent versions

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

If I start a fresh chat and ask to run echo $CI, I see it has value 1.

This affects my code as I rely on a CI env var (but I don’t set it anywhere in my env files). CI is a common env var name used by CI systems, hence why I consider this a bug.

I checked an older version of Cursor, and that’s not the case, the CI variable is not set. Here is that version which doesn’t have that issue:

Version: 2.2.35 (Universal)
VSCode Version: 1.105.1
Commit: 86d7e0c1a66a0a5f7e32cdbaf9b4bfbaf20ddaf0
Date: 2025-12-18T04:28:48.652Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 24.6.0

Steps to Reproduce

Open the chat, ask “run echo $CI”, observe 1 is printed.

Expected Behavior

Open the chat, ask “run echo $CI”, observe nothing is printed.

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.3.41
VSCode Version: 1.105.1
Commit: 2ca326e0d1ce10956aea33d54c0e2d8c13c58a30
Date: 2026-01-16T19:14:00.150Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

4 Likes
3

Hey, thanks for the report. Interesting case. We really shouldn’t be setting CI=1, since that’s a standard environment variable used by CI systems.

Could you check a couple things so we can fully understand what’s going on?

  1. Open a normal terminal in Cursor (not via agent chat) and run echo $CI. Does it also print 1?
  2. In your shell profile (.zshrc / .bashrc), is CI=1 being set anywhere?

If the variable isn’t present in the normal terminal and only shows up in agent chat, then it’s definitely a bug in the agent tool execution.

4
  1. In a normal terminal in Cursor, echo $CI prints nothing.
  2. I don’t have CI set in my shell profile .zshrc. Running env -u CI zsh -i -c ‘echo CI=$CI’ prints CI= (unset var), whether I run this myself or ask the Cursor chat to run it for me. (This command confirms I’m not setting CI anywhere in my shell profile or any files imported by it)
5

I’m facing the exact same issue. Any workaround to make sure Cursor doesn’t set the CI environment variable?

6

I’m facing the same issue. Every new agent tab starts with `CI=1`

7

I’m facing the same issue.

The following did the trick :
if [[ -n “$CURSOR_AGENT” ]]; then
export CI=
fi

2 Likes
8

if [[ -n “$CURSOR_AGENT” ]]; then
export CI=
fi

Thanks, that’s a good workaround.

To clarify for others: put that in your shell config (e.g. ~/.bashrc or ~/.zshrc), reload it, and restart cursor.

1 Like
9

:+1: Can confirm, I am also seeing this in recent builds of Cursor for macOS. It’s annoying for me because my team has special, CI-specific configuration in our test suite that only activates when the CI env var is present. Because Cursor now sets that var in its environment, when it runs its tests, it often gets tripped up because the test suite now believes it is being run in CI, when really it’s being run locally, and so it doesn’t have access to the rest of the environment that is only present in CI.

10

This is also causing problematic beahvior for me as well. I added a workaround by creating a cursor rule to always include unset CI in the problematic commands, but it feels like setting the CI env var will cause a lot of unexpected issues.

I would really love it if cursor provided more transparency and user control over which env vars are set by the cursor agent (ideally via settings.json so it can be source controlled for a repo). In many cases I’ve found that cursor is behaving very differently in the agent vs when I just run commands locally in my own shell. Having visibility into what env vars might be causing those problems feels very important and like low-hanging fruit.

11

Confirming too. It would be nice to get this patched as soon as possible.

12

This breaks a bunch of our build scripts. Needs to be patched.