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

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

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.

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.

13

Adding my +1 to this problem too. Would appreciate a fix, thank you :folded_hands:

Cursor agents also doesn’t respect my default shell (zsh) and run everything in bash - is it something that can be patched too?

14

This cost me multiple days of debugging to figure out, as the CI env var is recognized by my app’s tests and changes behavior. This is resulting in me switching off of cursor as the agent is unusable without being able to run tests reliably.

15

Its definitely a bug in the agent tool execution layer. Here’s Claude’s take after searching for an hour:

Found it! The cursor-agent-exec extension is the culprit. It explicitly sets CI:"1" in the environment for all agent shell executions.

Looking at the two matches in the code:

  1. Template executor creation:
const e = {env: {CURSOR_AGENT: "1", CI: "1"}};
  1. Command execution:
{workingDirectory: n, env: {CURSOR_AGENT: "1", CI: "1"}}

This is intentional behavior by Cursor. The cursor-agent-exec extension (the part of Cursor that handles agent shell tool calls) deliberately injects CI=1 alongside CURSOR_AGENT=1 into every agent shell environment.

The reasoning is almost certainly to ensure non-interactive behavior in tools commonly used in CI/CD pipelines. When CI=1 is set, many tools will:

  • Skip interactive prompts
  • Disable progress bars and animations
  • Suppress color output (in conjunction with NO_COLOR=1)
  • Use defaults instead of asking for user input
  • Change behavior of package managers (npm install becomes deterministic, etc.)

This is baked into the Cursor server extension at /home/<user>/.cursor-server/cli/servers/Stable-7150844152b426ed50d2b68dd6b33b5c5beb73c0/server/extensions/cursor-agent-exec/dist/main.js. It’s not configurable via settings - it’s hardcoded in the agent execution layer. Unfortunately, there’s no user-facing setting to disable it.

18

Sorry for any trouble this has caused! This will be fixed in the next release of Cursor.