diff --git a/active_admin_datetimepicker.gemspec b/active_admin_datetimepicker.gemspec
index 018908e..843e25f 100644
--- a/active_admin_datetimepicker.gemspec
+++ b/active_admin_datetimepicker.gemspec
@@ -16,7 +16,11 @@ Gem::Specification.new do |spec|
 
   spec.required_ruby_version = '>= 3.1.0'
 
-  spec.files         = `git ls-files -z`.split("\x0").reject { |f| f.match(%r{^(test|spec|features)/}) }
+  # 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 529 KB README png under screen/
+  # ended up published in the first place.
+  spec.files         = `git ls-files -z -- lib app vendor config exe bin README.md LICENSE.txt`.split("\x0")
   spec.bindir        = "bin"
   spec.executables   = spec.files.grep(%r{^bin/}) { |f| File.basename(f) }
   spec.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