How do you disable Python 3.14's remote-attach debugging for a hardened deployment?

### Three switches, one owner PEP 768 gave deployments a way to say no. The three opt-outs differ in scope and in when they take effect, but they share one property that is the source of most confusion in practice: **they are all properties of the process being attached to.** 1. **`PYTHON_DISABLE_REMOTE_DEBUG`** — an environment variable, read when the interpreter initialises. Set it in the container spec, the service unit, or whatever launches the process. Per-process, no rebuild, survives nothing but a restart of that process. 2. **`-X disable-remote-debug`** — the same thing on the command line, for a single run. Useful in a wrapper script or when the launcher owns the argv but not the environment. 3. **`--without-remote-debug`** — a build-time configure option. The support is not compiled in, so no environment or command line can turn it back on. This is the setting for an organisation that wants 'this interpreter cannot be attached to' as a property of the image itself, verifiable once at build time rather than on every launch. ### Verifying, not assuming A process reports its own state through `sys.is_remote_debug_enabled()`, which returns `False` when any of the three has taken effect. This matters more than it looks, because the failure mode of the command-line switch is silent: CPython accepts unknown `-X` names without complaint, so a run started with the option name spelled with underscores instead of hyphens starts happily with remote debugging still on. Nothing warns you. If the setting is load-bearing for you, assert it inside the process rather than trusting the launch configuration, and check it in whatever health or diagnostics surface you already expose. The environment variable has a matching trap of its own: it is read at interpreter startup, so assigning to `os.environ` later has no effect on the running process, and setting it in the operator's own shell affects only interpreters that shell subsequently starts. If you set it where you run the debugging tool and then find you can still attach, the setting simply never reached the process you attached to. Note also that disabling the feature does not remove `sys.remote_exec` from the `sys` module; the attribute is still there. What changes is the target's willingness to act on a request, so introspecting for the attribute is not a valid check. ### What the switch is actually for It is worth being honest about the threat model, because candidates often oversell this. Attaching requires the ability to write another process's address space: on Linux, the same user plus the platform's tracing policy; on macOS, root or the task-port entitlement, which is why an ordinary shell cannot even attach to its own child. Anyone holding that capability can already read your process's memory, patch its code, and extract its secrets by other means. Turning off remote debugging does not take that away. What it does give you is a narrower, auditable statement: this interpreter offers no supported, low-friction, in-process code-injection channel. That is worth having in three situations — a compliance regime that requires 'no runtime code injection' as a stated control; a multi-tenant host where operators have broad process privileges but should not have an easy path to customer data in live memory; and a hardened image where the smallest possible surface is a design goal in its own right. The controls that actually carry the load sit below the interpreter: user separation, the platform's tracing policy, dropped container capabilities, and who can obtain a shell where the process runs. ### Observability of attaches On the attaching side, `sys.remote_exec` raises the auditing event `sys.remote_exec` with the pid and the script path, so tooling that installs a hook via `sys.addaudithook` can record every attach it performs. That gives you a trail for your own tools and your own operators; it is not a defence against someone running an interpreter you do not control, which is another reason the operating-system boundary is the one that counts. ### A workable policy Decide once, per image, and make it visible: either the build supports attaching and you gate its use, or the build does not and you have accepted that a live process cannot be inspected this way. What you should avoid is the middle state — a fleet where nobody knows which processes are attachable, because the environment variable is set in some manifests and misspelled in others.