It depends on what you are trying to do.
You could always have a JAMF script call the local script and parse the results back to the JSS.
If you just after machines where script has had issues you could have it output to a file and build an extension attribute around that (some delay here, although not if there was an inventory update in the same policy).
Is there a reason for running a script locally and not from the JSS, I try to avoid local scripts unless completely necessary.

@Look We are running multiple Jamf Pro servers (at the moment 165 and growing) where we deploy a script locally. This script is used by multiple policies (on average 30) on each server. We don't want to create a script on the JSS for each policy otherwise there is too much maintenance to be done. Just a policy with the "Files and Processes" option.

You wouldn't need to create the exact script itself on each server, just another script that will run the local one and capture it's exit code and use that exit code for it's own exit status, if necessary.
I did a few tests, and I don't see a way for Files and Processes to capture the exit code of a local script being run. It just doesn't seem possible, but that doesn't mean there is absolutely not some way to do it. I would at least try creating a new JSS script that would run the local one and see if that works. It might be your only option.

@mm2270 I know, but it would be nice just to use the "Files and Processes" option. I'm in contact with the Jamf Support.

Jamf Support told me to create a feature request: https://www.jamf.com/jamf-nation/feature-requests/7111/jamf-pro-should-be-aware-of-exit-codes-in-files-and-processes

Please vote once :)

@anverhousseini Sure, upvoted. We can only vote it up once anyway :)

Feature Request??? This should clearly be a bug. Or are our expectations so low that a proper exit code should be considered an add-on feature..??? Anyways, upvoted.