I found a way to solve this, similar to T27721: [Segmentation] 2D Fast Marching crashes with 4D image and static segmentation: By transforming the time step from the reference image to the working image with

TimePointType referenceImageTimePoint = referenceImage->GetTimeGeometry()->TimeStepToTimePoint(t);
TimeStepType workingImageTimeStep = workingImage->GetTimeGeometry()->TimePointToTimeStep(referenceImageTimePoint);

in mitk::LiveWireTool2D::ConfirmSegmentation().
However, inside mitk::LiveWireTool2D there are a lot of uses of positionEvent->GetSender()->GetTimeStep() which all lead to a wrong timestep (e.g t = 2, although a static segmentation only has 1 timestep = 0).
That means:

1. I'm not sure about any negative side-effects which I don't see with my manual testing right now
2. There is a basic flaw in the design which should be discussed instead of just fixing the symptoms with the suggested fix

In T27800#211261, @kalali wrote:

2. There is a basic flaw in the design which should be discussed instead of just fixing the symptoms with the suggested fix

You are right. I have looked into the Tool2D code base. And I think the only proper solution is to make an complete overhaul and refactoring like I did for the AutoTools (3D). Meaning to check all implicit or explicite usages of time(points) and also clean up and generalize code, as also several 2D tools do a lot of same stuff but just a little bit different, may be due to different developers. But thats not good for maintenance an so on...

I havent looked at the fix. But I tend to just deactivate all tool for 4D images, if they currently do not work for 4D. And then make a real complete overhaul... Lets discuss that.