/classpath is inconsistent, one option would be /set classpath.
But it's lifespan is currently unlike any other /set command (in the jshell tool the duration of /set commands is the entire session, until /exit.). and it is an add, not a set.
Changing its lifespan is even more problematic, as it invalidates its main function.
Changing to an actual set functionality is at odds with VM semantics.
/classpath is also inconsistent because there is no corresponding support for analogous module functionality: add-modules, module-path, etc.
Finally, often what is wanted is re-evaluation in the context of an updated classpath, something that /classpath does not achieve.

I propose removing /classpath and adding command line flags:

    --class-path <path> Specify where to find user class files
    --module-path <path> Specify where to find application modules
    --add-modules <module>(,<module>)*
                          Specify modules to resolve, or all modules on the
                           module path if <module> is ALL-MODULE-PATHs
    --add-exports <module>/<package> Export specified module-private package to snippets

to the /reload and /reset commands.
These options will also be on a new /env command which (unless no snippets have been defined) is an alias for /reload -quiet, and which, with no arguments will print classpath, module info, relevant env vars, etc.

Also, add a /help subject "classpath" and maybe "modules".