Terminal errors: e.g. Argument list too long

[mentics]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I have a rule that instructs the chat agent to run certain bash commands. When the agent does there are errors appearing:

$ <. script to run 1>
<some output from my script so it looks like it succeeded>
environment: line 2233: /usr/bin/tr: Argument list too long
environment: line 2233: /usr/bin/base64: Argument list too long
$ <script to run 2>
--: eval: line 22: unexpected EOF while looking for matching `)'
--: eval: line 23: syntax error: unexpected end of file
--: line 1: dump_bash_state: command not found

Steps to Reproduce

Have a rule that says to run some scripts that are in the workspace and then tell the chat agent to run them.
To clarify on OS: I’m running Cursor on Windows but using ssh remote dev into Linux (ubuntu).

Expected Behavior

No errors and the chat agent is able to continue. As it is, it sees the error and so tries workaround.

Operating System

Windows 10/11
Linux

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.6.45 (user setup)
VSCode Version: 1.99.3
Commit: 3ccce8f55d8cca49f6d28b491a844c699b8719a0
Date: 2025-09-22T18:22:38.013Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.26100

For AI issues: which model did you use?

I tried it with Auto and grok-code-fast-1, same result.

For AI issues: add Request ID with privacy disabled

Request id: 07fc3b0a-39a6-4386-9f82-f7fffb92e65f

Additional Information

Possibly related issues:

Agent's terminal commands fail with dump_bash_state not found

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug When Cursor’s Agent runs terminal (agent’s terminal, not regular one), several problem occur the current directory is not the project working dir, but the OS root (i.e. ‘/’) most of commands fail with “–: dump_bash_state: command not found”. Many commands print also other errors: $ ps aux | grep -E “(npm|node|next)” | grep -v grep –: eval: line 1: unexpected EOF while looking for matching `)’ –: eval: line 2: synt…

Error on startup, seems to be related to dump_bash_state

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug After upgrading to version 1.6 (I’m not sure exactly when this issue first appeare, I tried a few previous versions from GitHub - worryzyy/awesome-cursor-download: Cursor历史版本下载、Cursor下载链接追踪器，Cursor beta版本、 Cursor下载中心 and it seems the problem exists in all of them), I got the following error every time I launch cursor: /bin/bash: line 33: warning: here-document at line 5 delimited by end-of-file (wanted `CURSOR_SNAP_EOF_%s…

Zsh Terminal State is Not Persistent in AI Assistant Due to dump_zsh_state: command not found Error

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug When using the AI assistant’s terminal tool on macOS with zsh as the default shell, every command execution is followed by a zsh:1: command not found: dump_zsh_state error. This appears to break the mechanism for terminal session persistence. As a result, each command runs in a new, isolated, and stateless session. The current working directory, environment variables, and any other shell state are reset after every comman…

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[mentics]

I can’t edit it, so I’ll reply instead:
It appears that this error occurs when I tell it to ‘source’ a script in a rule:

source scripts/something.sh

or

. scripts/something.sh

[deanrie]

Hey, thanks for the report. That makes sense - the source or . command is probably causing issues with how Cursor’s terminal state management works. When you source scripts, it can interfere with the internal dump_bash_state function that tracks terminal state between commands.

A few things to try:

• Instead of sourcing in your rules, try having the agent run the script directly with bash scripts/something.sh or make it executable and run ./scripts/something.sh
• If you need the script’s environment changes to persist, you could modify your script to export variables explicitly rather than relying on sourcing

The “Argument list too long” errors suggest the state dump is getting too large, which often happens when sourcing scripts that set lots of environment variables.

This is definitely a known issue that the team is working on - you can see similar reports in the threads you linked.

[mentics]

Thank you for the reply. Prior to sourcing it like this, I was using it as an –init-file in terminal.integrated.profiles.linux so it would setup the environment. But I removed it from there because I was trying to find ways to get the terminal to stop hanging. The terminal hanging issue happens quite often and is rather frustrating.

I can’t just run them as bash scripts as you suggest because then it won’t persist the environment. They have to be sourced in order to modify the environment of the parent shell. I could have the agent call it as part of every command which is also what I was doing previously, but again… I went away from that trying to find ways to avoid the hanging terminal issue.

FYI: it’s not setting many environment variables. printenv | wc -c at the end of the script indicates only ~3000 characters.

[mentics]

Some info I found:

source $CMD causes problems but source <(${CMD}) doesn’t, so that could be useful. However, it seems that each terminal command might be a separate env so… not sure this would work anyway. I need each chat session to have a unique id, but it seems there is no consistent way to interact with the shell because you might get a new one. So, I’ll have to provide an id to the agent require it to remember.