As evidenced by the sshuttle ... | cat test, the problem is indeed unrelated to perl. The sshuttle is a python program. Why have you chosen to raise the github issue with Capture-Tiny instead of sshuttle?

I've already hinted on three possible workarounds you could use on the perl size, that may or may not work at all. (Ignore SIGTTIN SIGTTOU before exec; Explicit redirect/close(STDERR); Setting up the task as session leader via IO::Pty.) Did you try any of these?

It is unlikely anyone on PerlMonks is going to debug python programs for your benefit or amusement. And we cannot Chuck Norris^(*) your code.

Why do you make emphasis here on what language the programm is written ? As I told it is just an external program a Perl script interact with by IPC. As for me it is still to be proven that sshuttle is culprit. Well, there are some _signs_ that that it could be for sshuttle, but as I told you I am still not sure. And this why I chose adverb _probably_ in my statements.

I don't blame anybody I just look for help. ))) as for your workarounds , some of them I already tried, and probably will try others ... I just need some time to check, will let you know later

Simply try the same invocation sshuttle -D ... 2>&- | cat (with the redirect) and see how it behaves.

However, there seems to be a fundamental misconception about the workings of process environment. A shell command line does not contain or isolate the task. This is how a daemon can work in the first place: it detaches from shell and terminal and starts running on its own. You have indicated that the exit status of the command is of interest to you. But this may be largely irrelevant to the working of your service. The daemon will have forked at least once; the process writing to your pipe/stdout is the child not the $pid you forked.