diff --git a/active_admin_sidebar.gemspec b/active_admin_sidebar.gemspec
index 353c8f5..3ea52d9 100644
--- a/active_admin_sidebar.gemspec
+++ b/active_admin_sidebar.gemspec
@@ -13,8 +13,11 @@ Gem::Specification.new do |s|
 
   s.required_ruby_version = '>= 3.1.0'
 
-  s.files         = `git ls-files`.split("\n")
-  s.test_files    = `git ls-files -- {test,spec,features}/*`.split("\n")
+  # Whitelist, not a reject list: a new directory in the repo does not
+  # reach consumers until it is named here. The reject form needs a new
+  # pattern every time the repo grows one, and that is how the
+  # Capybara suite under spec/ ended up published in the first place.
+  s.files         = `git ls-files -z -- lib app vendor config exe bin README.md LICENSE`.split("\x0")
   s.executables   = `git ls-files -- bin/*`.split("\n").map{ |f| File.basename(f) }
   s.require_paths = ["lib"]
 
diff --git a/spec/support/capybara.rb b/spec/support/capybara.rb
index e09d7e9..afdcda4 100644
--- a/spec/support/capybara.rb
+++ b/spec/support/capybara.rb
@@ -2,7 +2,28 @@
 
 Capybara.server = :webrick
 Capybara.register_driver :cuprite do |app|
-  Capybara::Cuprite::Driver.new(app, headless: true, window_size: [1280, 800])
+  # Chrome intermittently fails to hand back a websocket URL on GitHub
+  # runners and the leg dies with Ferrum::ProcessTimeoutError. The cause
+  # is not established. Two theories were tried and both are ruled out:
+  #
+  #   * /dev/shm exhaustion -- Ferrum already passes
+  #     --disable-dev-shm-usage by default
+  #     (Ferrum::Browser::Options::Chrome::DEFAULT_OPTIONS), so the runs
+  #     that failed were already using it.
+  #   * the ubuntu-24.04 AppArmor restriction on unprivileged user
+  #     namespaces -- the sibling repo capybara_active_admin passes
+  #     --no-sandbox and --disable-setuid-sandbox already, and flakes
+  #     the same way.
+  #
+  # So: --no-sandbox is kept because it is harmless on a single-tenant
+  # CI VM serving only this suite's dummy app and may still help, and
+  # process_timeout is raised from Ferrum's 10s default because a slow
+  # start is at least a failure mode a budget can cover. Neither is
+  # demonstrated to fix it. A rerun is currently the answer when it
+  # happens.
+  Capybara::Cuprite::Driver.new(app, headless: true, window_size: [1280, 800],
+                                process_timeout: 30,
+                                browser_options: { 'no-sandbox': nil })
 end
 Capybara.javascript_driver = :cuprite
 Capybara.default_max_wait_time = 5