Review package access and updates

Installed packages run in separate sandboxes by default. The installation review is the point at which you decide what a package and the dependencies loaded with it may access.

The card describes effective access in ordinary terms: network destinations, readable or writable files, environment variables, system information, programs, native libraries, and Smudgy features such as sending commands, mapper changes, session access, display, storage, or protocol data.

A dependency runs inside its parent package's sandbox. It does not receive a second independent grant. Review the whole resolved group named by the prompt, not only the package at the top.

No permission list can prove that code is well behaved. It limits the damage available to the sandbox. A package allowed to send commands can still send the wrong command; one allowed to display a pane can still mislead the user.

Some allowed operations have effects outside Smudgy's package sandbox. The permission review displays Effectively full access when a package can run another program, load a native library, or write outside its private data directory.

A listed executable or library is not itself sandboxed. Once started or loaded, it may act with the same operating-system authority as the user. Treat the red warning as a trust decision even when the package itself still says Runs in sandbox.

An outside-data read receives a caution because it can expose personal files. Requests confined to $DATA affect the package's own managed directory. Check the displayed target instead of relying only on the permission category.

An update that fits the existing grant can load without widening access. When a newer version asks for more, smudgy holds it back and shows the added requests.

Choose Keep current version to retain the last version that fits the grant. Choose Grant & update only after the new capability makes sense and you have reviewed the new source. A version may also be held back because it requires a newer smudgy release; permissions cannot override that compatibility floor.

Disabling a package stops it from loading at the next reload and removes the automations and widgets it registered for the current runtime reload. Its files, configuration, and lock entry remain.

Removing a package deletes the installed reference for that server. Smudgy may prevent or warn about removal when another installed package depends on it. Review dependents rather than forcing a partially broken package graph.

When the last installed reference to a package is removed, smudgy can clean up storage managed for that package. Export anything its README says you should keep before uninstalling. Files written to a separately granted path are outside that managed storage and may remain.

With Advanced scripting features enabled, an installed package can be marked trusted with Remove sandbox. Trusted code runs with the same broad authority as your own modules and shares their main script isolate. Its manifest permission list is no longer the enforcement boundary.

The label is literal: do this only after reviewing the exact package and version as code you would have written yourself. Do not use trust to silence a permission prompt. Restore sandbox returns the package to enforced consent.

Local package authors have a similar Develop unsandboxed option. It is a convenience for local debugging, not a requirement for subprocesses or native libraries: released packages can declare scoped run and ffi entries. Return to the manifest sandbox before publishing so the tested behavior matches the permissions an installer will review.

For the author-facing permission taxonomy, see Permissions, sandboxing, and trust.