I’ll try… When you define a command in a clispec, the CLI engine by default doesn’t know what that command “wants to do” - e.g. even if you define arguments in the clispec, the command may also want to interact with the user, e.g. prompt for additional info and receive the resulting user input. Thus the CLI sends any user input to the command. This is typically no problem when you run the command in an interactive CLI session, since there won’t be any “user input”.
But when you run the command from within a script, that “user input” would have to be - or at least could be - present in the script file. Thus the CLI will by default send any data in the script file, that follows the command invocation, to the command. I.e. the “commit” in the file is actually sent to your command’s standard input (as are the “exit” commands in @cohult’s example). Your command doesn’t read it, but it is nevertheless “gone” when your command finishes.
noInput tells the CLI that your command doesn’t want any “user input”, and the CLI will then not read any more input from the script file until your command has finished, at which point it will treat the remaining text in the script file as CLI commands.