PlaceholderExecutable does not bother listening for a closed connection as such, it just lets any nested step actually using the agent fail if the connection dies in the middle. Usually this is fine, but there is a corner case where it is probably wrong (unconfirmed): if an agent is disconnected and reconnected during the first sh in

node {
  sh 'sleep 999'
  sh 'sleep 999'
}

then the second sh could fail since it would be using the old Channel, even when the first sh succeeds because the DurableTaskStep.Execution recomputes the FilePath after the ChannelClosedException. (But if Jenkins restarted during the first sh after the reconnection then it should work, since the FilePath would be reconstructed from a FilePathPickle.)

The fix may be tricky since FilePath.channel is effectively final, so currently whatever workspace is passed from PlaceholderExecutable will be used for the duration of the block. Perhaps BodyInvoker.withContexts should support offering a Provider of contextual objects—in this case something that caches a FilePath so long as it is valid (!Channel.outClosed?), and otherwise falls back to FilePathUtils.find like FilePathPickle.