[Bug]: 0.10(.x) MCP started erroring with "Transport closed"

[kurtextrem]

Which fff frontend?

MCP server (fff-mcp)

has logs

2026-07-23T13:31:27.986733Z  INFO          tokio-rt-worker fff_mcp: Exiting after 900s of inactivity (idle_timeout_secs=900)

Description

For some reason, 0.10.0 and 0.10.1 started closing the MCP or something? In Codex (UI) I get this:

tool call error: tool call failed for `fff/multi_grep`

Caused by:
    Transport closed

tool call error: tool call failed for `fff/grep`

Caused by:
    Transport closed

Which didn't happen in the previous version. I assume the cause is the line I copied out of the logs, so ... maybe it shouldn't quit if Codex isn't smart enough that it has to restart the MCP or something?

[dmtrKovalenko]

Unfortunately this is something that we don’t really control. 15 minutes of inactivity is a huge chunk which you can control from args as well so it is safe to assume that it is dead

Unfortunately mcp protocol isn’t always closed correctly by other harnesses like Claude Code which sometimes leads to a lot of lingering processes of fff - this is definetely worse than broken sessions after large inactivity gap

But maybe we should bump this to an hour

[kurtextrem]

Interesting, thanks. I'll try out if FFF_MCP_IDLE_TIMEOUT_SECS=0 helps in the Codex case.

[exsesx]

Also suffering from this

[davidarny]

Interesting, thanks. I'll try out if FFF_MCP_IDLE_TIMEOUT_SECS=0 helps in the Codex case.

Did that end up helping?

[kurtextrem]

Interesting, thanks. I'll try out if FFF_MCP_IDLE_TIMEOUT_SECS=0 helps in the Codex case.

Did that end up helping?

Haven't run into the same error since!

[catursurapam]

smae here, my agent said transport error ("pipe is being closed")

[arthurgeron]

Interesting, thanks. I'll try out if FFF_MCP_IDLE_TIMEOUT_SECS=0 helps in the Codex case.

This is actually worse; you'll have one server instance per AI session hanging on your machine until you reboot.

I never expected to face this when installing this tool; it should be clearly advertised in the README as a drawback/warning. We are forced to pick a random number that will likely never fit multi-hour or day sessions, or have zombie instances.

I'd say making it able to gracefully shut down alongside their parent sessions is a must-have feature.

I'll be uninstalling this for now

[dmtrKovalenko]

It will be exited properly if your AI is closing the server properly. If the claude code is dying and not sending exit signal to mcp server there is not much we can do except having this kind of idle timeout

If the server is sending exit signal fff will exit no matter what timeout set

[arthurgeron]

It will be exited properly if your AI is closing the server properly. If the claude code is dying and not sending exit signal to mcp server there is not much we can do except having this kind of idle timeout

If the server is sending exit signal fff will exit no matter what timeout set

I've had multiple Claude sessions telling me FFF was dying mid-session; On my setup, the "arbitrary" short timeout was the default behavior. That is how I got to this issue #.

If the tool sets up a hook on Claude to kill FFF on exit, I'm pretty sure it would, but that alone isn't very reassuring, as Claude and all the other model wrappers can be glitchy. I'd be more at peace if the server itself would check if the parent session is alive

[kurtextrem]

Interesting, thanks. I'll try out if FFF_MCP_IDLE_TIMEOUT_SECS=0 helps in the Codex case.

This is actually worse; you'll have one server instance per AI session hanging on your machine until you reboot.

It works fine in Codex.