command4 is currently running, it is possible to do this pretty straightforwardly:
$ fg && right_command5 && command6
This is essentially what you were already doing to start
command4 in the first place.
wrong_command5 and the rest will be replaced and never execute.
I think that behaviour is going to be unexpected to you, so read on for an explanation of where things don't work the way you thought they would.
However: note that your original command sequence does not do what you think it does. When you do:
$ command1 && command2 && command3
Running command1 ...
Running command2 ...^Z
$ fg && command4
command2 will be resumed, but the rest of the chain will not be. Stopping
command2 with Ctrl-Z means that it exits abnormally with
SIGTSTP (-20). Since
command2 exits non-succesfully,
&& short-circuits out of the chain and
command3 will never run.
command4 will start immediately after the end of the resumed
You can watch this behaviour in action by replacing the
$ command2 || echo Running command3, exit was $?
+ Stopped command2
Running command3, exit was 148
You have to list out the entire subsequent chain of commands when you resume if you want the behaviour you're aiming for. Alternatively, if you want to be able to stop and resume whole command chains you need to run them in a subshell:
$ (command1 && command2 && command3)
In that case, though, there's no way to intercede and replace a command at all.