Good catch, thanks for reporting @joshuaclayton. I'm not sure what's the right solution here, but a note in the README is totally pertinent. Thanks!

This seems like a big risk to me. Would you consider disabling the sandbox option when this gem is present?

You can use config.disable_sandbox for this.

That's a good idea @ghiculescu. I'll be happy to merge a PR that disables the sandbox option when console1984 is enabled.

Can we explore other directions (e.g., saving audit logs in another database)? To avoid accidental destruction, I always use sandbox mode first to check if commands work as expected.

@jorgemanrubia #101

I can make it optional if you prefer but IMO it's better to be strict here and then loosen it up later if other options are added.

I think optional but disabled by default is a sensible approach here @ghiculescu.

We've been using another database to store our console access with some success:

class Console1984Record < ActiveRecord::Base
  self.abstract_class = true
  self.belongs_to_required_by_default = false

  connects_to database: { writing: :console_access, reading: :console_access }
end

In config/application.rb:

config.console1984.base_record_class = "::Console1984Record"

The user that connects to that database can insert and can update sensitive_access_id but can't delete records. It's certainly not 100% tamper-proof, but we're also broadcasting console access via other means as some extra insurance.