KM doesn't know what variables you will want to access in the shell script, so it makes as many available as it can/should. These will include all your global variables and any local variables used in that macro before the "Execute a shell script" action.
But, as Peter explained, the amount of data you can pass to the instantiating shell in this way is limited -- if it will be over 100k (I assume kB) then KM will not pass some and will add log entries to let you know.
The option @ComplexPoint... erm... pointed out was introduced in KM v11 and now allows you to control which variables are made available to the shell, helping ensure that what you want included is by excluding the ones you don't.
Local variables are only available within the currently executing instance of a macro. Even if you have "Macro A" with variable local__a and have it running multiple times concurrently, each macro's local__a is separate from the others, and a shell script action within "Macro A" will only see the local__a belonging to its executing instance.
The list in the action's options isn't so much a list of actual variables, it's a list of variable names in use across the Editor. For globals that amounts to the same thing but for locals anything you pick will be the instance for that macro, because of the above scoping. If the local variable doesn't exist in your macro but you tick it in the options and then try to use it in the shell script it will evaluate as an empty string, ''.
Which just leaves:
If you've got round this by eliminating all your unneeded variables, or you aren't actually using Local__files in your shell script -- no worries. But if you do need to use it and it's a mahoosive list of file paths, you'll need to present it to the shell in a different way or run the risk of errors whenever the list breaks the 100k limit.