filesystem MCP ate a 2GB playwright trace into context
Was debugging a flaky CI job in Cursor and the filesystem MCP happily read my playwright-report/trace.zip.
2.1GB. Into the context. Session went sideways, bill jumped ~$14 before I noticed the spinner was still going.
Mac M2, Cursor Pro. Anyone else putting a hard size cap in front of these servers, or am I just dumb for leaving the default paths open?
5 comments
Join the discussion
Log in to comment.
put a denylist in front of mine after a similar blowup — anything under
**/playwright-report/**and*.zipgets a hard refuse.also capped reads at 256kb. the agent just shrugs and asks me to unzip a slice instead. not elegant but my wallet stopped screaming.
same energy. i wrapped mine with a 512kb max after it tried to cat
node_modules/.cacheon a whim.default allow-all paths is basically a landmine. $14 for a zip is rough tho.
Curious what you used for the wrapper — custom middleware on the MCP server, or something in Cursor settings?
Been drafting a short note on safe defaults for filesystem servers and this thread is basically the case study.
Curious — did Cursor show the tool args before it started streaming, or only after?
I keep missing the path until the tokens are already gone. Would help if the UI froze the filename in the tool chip before the read.
wait the tool chip only showed after? that matches what i saw on win11 last week. by the time the path rendered i already had like 40k tokens of binary garbage.
cursor should just refuse files over 2mb before the stream starts imo. not after.