Giving access to folder-like services via AccessOutsideWrites would essentially bring back a game I previously had to shut down due to scripting vulnerabilities (Abuse of Ban API, InsertService etc) without having to tell hundreds of its creators (most who will have moved on) to update their maps.
Please make this happen 
Modules required with require(id) seem to escape the sandbox of the requiring script’s container.
I was able to ban myself with Players:BanAsync() using only the RunServerScript and AssetRequire capabilities.
Using getfenv or setfenv is entirely broken when sandboxed even when allowing all permissions, is this intentional due to its enviornment changing nature? Because I had the enviornment sandbox option turned on.
The current thread cannot call 'getfenv' (lacking capability Unassigned)
Yes, getfenv and setfenv are not available because they break out of our Sandbox.
Will this prevent exploiters from inserting scripts into places like CoreGui?
Hey there, I was acc reading about this lol 
So does this exactly prevent exploiters fully?
This feature has nothing to do with exploits
Noticed I can no longer call game:getdescendants() without an error.
“The current thread cannot access ‘StreamingService’ (lacking capability Assistant)”
I currently do this to iterate through all parts of the game in order to properly setup sounds, clean up some welds etc. Feel like this behavior doesnt need to break, rather it should just not iterate over stuff like StreamingService
Still a problem! When’s the next update?
StreamingService issue is not exactly related to this feature, that issue should now be fixed.
Unfortunately, the fix has gotten delayed and won’t be available next week, but sandboxing propagation to require(id) module execution is ready and should come out in version 654.
Unfortunately I’m still experiencing this bug, which makes it very hard for me to implement what I want to do with this feature.
Seems there is a sandbox breakout method with Tool instances as they will reparent to the characters.
SandboxBreakout.rbxl (58.1 KB)
This breakout method works with RunServerScript enabled or disabled (you just have to pick up the tool before the 8 second timer runs out with RunServerScript enabled)
Not sure how this could be fixed in this case, anyone using this feature would have to blacklist tools manually.
EDIT:
This may also apply to anything else that gets parented on touch with standard humanoids characters, such as hats.
That opens insane potential to a modding with user-experiences!
That would be amazing if you could configure script capabilities during runtime or either during inserting a model there, so people don’t access areas in the game that you don’t want to!
Ability to allow or ban certain services would be also amazing!
@WheretIB
Since Sandboxing is a thing now. Roblox should remove the restrictions on InsertService.
People do want this and now that we have Security Restrictions for scripts in place I say we bring back InsertService and Allow people to insert free models without having them added to their inventory:
Thank you for the report, we will have an update to handle that!
Can we get private modules back? Some of us may use them for legitimate reasons, for example, to run a business. I’d like to protect my property without worrying about losing out on revenue.
Hoping your code isn’t gonna get stolen in a niche community with children as the main demographic is copium at it’s best. Unless I’m missing something here, there’s literally no reason to not allow private modules to run in a sandboxed container.
I imagine this is yet another bandage for the “malicious code in free models” epidemic. If newbies aren’t bothered enough or aren’t capable enough to read the open source code, but are capable enough to sandbox it, why not just allow private modules as well?
Vouching for this.
My case is also business related. I would like to have private modules return, as the community him and I are involved in mainly contain users with malicious intent, which goes as far as to unauthorized distribution, use of code not made by the original writer and re-selling “valuable” code within the respective community.
At the moment, since the shut down of private modules, the community we both engage in heavily relies on code obfuscation (NOT PUBLISHED ON THE TOOLBOX) which is not only horrible for performance, but our only way to keep code hidden and non-distributable from threat actors.
