It depends on the platform. If you're running a Linux or Unix server, the operating system, background jobs will pretend like the user pressed the END key whenever a process gets to a point where it would normally wait for user input.

On Windows servers, the OS doesn't really provide anything that differentiates between a foreground and background process - there isn't a notion of a "background process" on Windows (except for a Windows service, which is something else entirely). Instead, when you spawn an Appx background job on a Windows server, we just start another copy of Appx (minimized). Try running Appx on a Windows server without running in client/server mode - run a background job that needs to wait for user input. When you spawn the job, you should see another copy of Appx show up in your task bar. Open that window and you'll see the background job running. You can interact with it using the keyboard and mouse. It's just a second Appx session that starts in the right place, has a copy of all of the parent session's important data, and starts minimized. Just like the specification says: separate task allowed? Very handy for debugging background jobs.

However, that's an old feature that was written before we had a client/server configuration. If you connect to appxdsvc or winappxd, the broker creates an invisible desktop for the engine sessions - that means that you can't get to any background sessions. We should probably modify the Windows engine so that it notices that you're running in client/server mode and behaves more like Unix/Linux of you are.