It's possible to create a job that Jenkins won't reload after a restart.
i.e. the job "vanishes" after a reboot.

A "Multi-configuration" project (aka a matrix job) can set a "Combination Filter" to restrict the combinations of axis values that will be run.
This filter is a groovy expression.

The job configuration page (and the Jenkins DSL plugin) allows the user to specify a filter of the form
(axisName.startsWith("prefix")).implies(otherAxisName=="otherValue")
This is valid groovy, and the user is allowed to "save" the result (and it works as one would expect).
However, if one later restarts Jenkins, the job fails to reappear, and there's an exception in the Jenkins log saying:

Failed Loading job myMatrixJob
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method java.lang.String startsWith java.lang.String
at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:150)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:77)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:103)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:100)
at org.kohsuke.groovy.sandbox.impl.Checker$checkedCall$0.callStatic(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:50)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:157)
at Script1.run(Script1.groovy:1)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.run(GroovySandbox.java:139)
at hudson.matrix.FilterScript.evaluate(FilterScript.java:45)
at hudson.matrix.FilterScript.apply(FilterScript.java:85)
at hudson.matrix.Combination.evalGroovyExpression(Combination.java:101)
at hudson.matrix.Combination.evalGroovyExpression(Combination.java:91)
at hudson.matrix.MatrixProject.rebuildConfigurations(MatrixProject.java:638)
at hudson.matrix.MatrixProject.onLoad(MatrixProject.java:505)
at hudson.model.Items.load(Items.java:320)
at jenkins.model.Jenkins$17.run(Jenkins.java:2651)
at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:282)
at jenkins.model.Jenkins$7.runTask(Jenkins.java:904)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:210)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1176)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:795)

Note: This is NOT a bug with the sandbox defaults (that's a separate issue) - the problem is that the security restrictions being applied when Jenkins starts up is different to the security restrictions being applied when Jenkins is running. The user should not be permitted to define a job (via the configuration page) that Jenkins later refuses to load on startup - Jenkins should not discard a job that was previously deemed valid.

There are 3 factors here:

• the validation is not being applied when the user edits the job, so that the user is not informed that their job definition is illegal when they enter the illegal matrix configuration.
• the validation is not being applied when the job is run, so that this "illegal" code is executed despite it being "illegal".
• when (on startup) a job is deemed to contain an "illegal" expression, Jenkins hides the job (from the UI) so that the user is unable to edit the job to fix the problem (I would suggest that an illegal job should be loaded and made available for editing, but builds of that job should exit with an error until it was fixed).