I hit this same :invalid_arg error and got some help from the guys in the Elixir Slack (@LostKobrakai included 
).
I needed to change the args to a list of char lists like so:
defp peer_args do
[~c"-loader", ~c"inet", ~c"-hosts", ~c"127.0.0.1", ~c"-setcookie", ~c"#{:erlang.get_cookie()}"]
end
Very nice thank you for that. So I updated peer_args and progressed to a new error 
Evaluation process terminated - an exception was raised:
** (ArgumentError) errors were found at the given arguments:
* 2nd argument: invalid option in list
:erlang.open_port({:spawn_executable, ~c"/Applications/Livebook.app/Contents/Resources/rel/vendor/otp/erts-14.0.2/bin/erl"}, [{:args, [~c"-sname", [102, 105, 114, 115, 116, 95, 112, 101, 101, 114, 95, 110, 111, 100, 101, 64 | :localhost], ~c"-loader", ~c"inet", ~c"-hosts", ~c"127.0.0.1", ~c"-setcookie", ~c"NwYcxH4MNAGsdadsjh1TP7kefauOlwoRXq1", ~c"-detached", ~c"-peer_detached", ~c"-user", ~c"peer", ~c"-origin", ~c"g1h3KDN0aW9sbDRd0LWxpdmVsdfib29rX2FwcEsadfdsafdBEYXZpZHMtTWFjQm9vay1Qcm8AAAeIiAAAAAGT7Reg="]}, {:env, []}, :hide, :binary])
(stdlib 5.0.2) peer.erl:309: :peer.init/1
(stdlib 5.0.2) gen_server.erl:962: :gen_server.init_it/2
(stdlib 5.0.2) gen_server.erl:917: :gen_server.init_it/6
(stdlib 5.0.2) proc_lib.erl:241: :proc_lib.init_p_do_apply/3
So bringing it back to the original goals of this post:
The best approach so far seems to be
System.cmd("elixir", [Path.join(__DIR__, "action_test.exs")])
Which starts node under hood with no worries of dependency overlap issues with the parent process. I’m starting to R&D how to refine and deal with possible elixir --no-halt scenarios with cleanup timeouts etc.
In general though I really like exs scripts with Mix.install. I also want to explore storing script files in DB, then dynamically load + run them in my app. I think this will check all my desired requirements.
If you need an isolated VM you can use :peer to start one. No need to drop to shells or CLI stuff.
Absolutely not, maybe for you. The problem with starting random processes like this is that sooner or later you will make a memory leak, and this will render all the fault tolerance feature useless.
@LostKobrakai All the debugging above is for the :peer approach in PeerNode
@D4no0 instead of ‘best’ perhaps I should have said ‘easiest’ so far
I’m learning and trying to understand more. If both :peer and CLI approaches start a new beam instance, why is one considered better/worse?
Architecture ideas so far:
R&D Notes:
Why all this?
I’m working on an open source app idea for event handling. It will be an ‘if-this-then-that’ application where ‘if-this’ logic is no-code gui frontend and the ‘then-that’ portion is Elixir code (probably exs mix install scripts). The essence of the idea is to find the right balance between code and no-code / low-code tools.
