Now filters out these internal sbt commands before passing arguments to the template resolver.

This means that sbtn is will launch an sbt session in the current directory. Instead, if sbt new is detected on bash/batch (search for sbt_new=true), we should probably ignore --client, and call the "server", which inside of Main.scala is going to short-circuit and does special thing for new anyway.

Now filters out these internal sbt commands before passing arguments to the template resolver.

This means that sbtn is will launch an sbt session in the current directory. Instead, if sbt new is detected on bash/batch (search for sbt_new=true), we should probably ignore --client, and call the "server", which inside of Main.scala is going to short-circuit and does special thing for new anyway.

Thanks for the suggestion! You're right that handling this at the launcher level is cleaner.

I've updated the PR to skip the native client entirely when sbt new or sbt init is detected. The fix adds an early return in isRunNativeClient() (bash) and the equivalent check in sbt.bat (Windows) - when sbt_new=true, we just use the full JVM instead of the thin client.

This avoids the whole issue of internal commands leaking into the template arguments since the native client path is never taken for these commands.

the CI failure appears to be unrelated to this PR. the NotImplementedError is from a scripted test that uses ??? in its build.sbt to test error handling - that's expected behavior. the launcher script changes only affect the execution path for sbt new/sbt init commands and don't impact the server tests

All passed!