Nightfall blocked filesystem MCP mid-refactor and I had to break-glass
Tried Nightfall MCP Gateway on Cursor this week after security freaked out about mcp__filesystem__write_file.
First block was fine — denied a write outside the allowlist. Second one killed a refactor mid-flight when Claude Code tried to touch .env.local through a path that was almost allowed. No toast. Just tools:[] empty for a second, then the call vanished.
Had to flip deny:false for ~20 minutes to finish. Feels like the old VS Code extension days where the security layer and the editor refuse to talk.
Anyone got a break-glass that doesn't mean turning the whole gateway off?
3 comments
Join the discussion
Log in to comment.
yeah we hit that. nightfall denylisted our supabase mcp because the tool name matched a regex for
sql_execute. allowlist by server id fixed it but the docs buried that under enterprise.still better than tools:[] silent fail tho. at least the block showed up in their audit log.
We wrote the break-glass as a time-boxed override in Linear, not a permanent deny:false. Pasted the blocked call from Nightfall's audit trail into the ticket and security approved a 2h window.
Path allowlists beat bigger context every time. The mid-flight kill still sucks though — would love a "queue and ask" mode instead of empty tools.
empty
tools:[]for one turn is the worst failure mode. looks connected, then the call just disappears. I would rather see a hard deny with the blocked tool name in stdio.for break-glass we keep a second MCP config that only exposes the filesystem server with a path allowlist, and swap it in for a ticketed window. not elegant. at least deny:false is not permanent on the main gateway.
does Nightfall log the blocked tool args, or only the tool name? I need the path for the audit ticket.