[jdjdjjsjs]

It still doesn't make sense. If this is the better approach, then why isn't it the default.

Why is it enabled (in a way that is extremely difficult to reverse) by copy pasting something in the Terminal?

I'm pretty sure this is a bug that will likely be resolved in a couple of minor updates.

Edit: Also, this is extremely user hostile. And it is security hostile. The user and securoty hostile bit isn't giving access when the user pastes a location in the terminal. The hostile bit is completely ignoring the users action when they subsequently try to disable access through the File Access dialog. And it's security hostile because the OS is making it difficult to remove access, not enable access.

[ridiculous_fish]

It's enabled by copy and pasting because the pasteboard carries capabilities.

I agree it's a bug that these cannot be removed, but it's not user hostile. You wouldn't say Linux is "extremely user hostile" because it allows Terminal to access ~/Downloads without prompting.

This is an extra layer, it alone does not give the app access. Apps which retain this permission are still governed by sandboxing and filesystem permissions, just like on Linux and Windows and Mojave.

[jandrese]

It's hard to imagine how this could be accidental behavior. It is much too specific. The only way I could see it being a bug (or incomplete feature) is if maybe there's supposed to be a prompt asking if you want to grant permission first that isn't working. And maybe some sort of permission manager that lets you add/revoke said permissions without a laborious reboot into a diagnostic tool.

[jasonlotito]

> It's hard to imagine how this could be accidental behavior.

Ooops, I meant to drag it onto my desktop, but I accidentally dropped it onto my terminal.

It's very easy to imagine how this could be accidental behavior.

[jandrese]

What I'm saying is that the underlying development work necessary to create this feature can't be an accident.

Accidentally triggering said behavior is a different topic entirely.