Well, I don’t know whether there is a specific meaning of “sandbox” in the context of FS2020 - where did you pick up that term? Here in the SDK forum? - but I can give you a general definition (in the context of software / development):
A “sandbox” is a “space” within which a given process - or an entire application - is confined. So don’t just think of a “separate computer not connected to other production systems”: it is really an “address space” which the “process” may access - but nothing beyond!
That’s as abstract as it can be, I know, so let’s quickly make a concrete example: web browsers (Firefox, Chrome, IE, …) typically implement a “sandbox” (a dedicated address space) within which they execute the JavaScript downloaded from various web sites.
Have a look at some of the JavaScript downloaded from various locations when you visit e.g. flightsimulator.com:
Do you trust all those sources? Some yes, some no (the screenshot is from a “script blocker” called uMatrix, in case you wondered: a Firefox extension)… but your browser trusts none of those sources really!
But still the browser needs to execute that code (JavaScript). After all, that’s what you - as a user - expect it to. But what if a malicious piece of code would try to access your files stored on your computer? Certainly you wouldn’t want that either! Except of course you wanted to upload a file to a web page - but even then you don’t want to give permission to the actual JavaScript!
Enter “sandboxes”: so the JavaScript is executed within a “safe environment” where it is given certain permissions. For instance it may do computations, taking away precious CPU power - but perhaps only to some extend (you don’t want a web site to mine for crypto currencies while you’re visiting it). It may access your browser history. It may access certain key strokes (shortcuts).
But a JavaScript certainly mustn’t access your local files. It must not even be able to access your RAM at will! It must not be able to download resources from any location of the web except from where the Script originated itself (“cross border scripting”). Etc. etc.
And the browser takes care of all this by putting the “process” (which executes the JavaScript) in a dedicated memory area, the “sandbox”, given (or rather) taking away “privileges” to that process, so I can only access and execute a well-defined set of API (“functions”) which are considered “harmless”. But still enough such that the JavaScript can do “meaningful stuff”.
Now you can imagine how difficult it is to define “meaningful stuff”. Even “harmless stuff” like giving JavaScript access to “high precision timers” on your computer might seem to be a “trivial” and “good thing” to do. After all, you want that e.g. a website could measure your download/upload speed with the highest precision. Right?
Well, it turns out that when you give JavaScript access to high precision timers (which measure the time in the range of nano-seconds) that “evil” JavaScript can mis-use this for various “timing attacks”. And yes, that was (and is) a real issue, e.g. here https://bugzilla.mozilla.org/show_bug.cgi?id=1217238
And even when you have defined the “useful stuff JavaScript (or generically again: a process) is allowed to do” the even harder thing is to make sure that your sandbox is really sealed!
The concept of “sandbox” doesn’t just exist in the context of web browsers. The programming language Java also has a sanbox, and since JavaScript (possibly compiled to “web assembly”) is also used to extend FS 2020 functionality I guess FS 2020 also has a sandbox for its extensions (in the context of so-called WASM modules).
I hope that helps 
