PowerShell Execution Policy e Activate.ps1: errori tipici su Windows

Perché PowerShell rifiuta Activate.ps1, come leggere la policy con Get-ExecutionPolicy -List e come attivare la .venv su Windows senza abbassare la sicurezza.

Hai creato la .venv, scrivi .venv\Scripts\Activate.ps1 in PowerShell e invece del prompt (.venv) ottieni un errore rosso che parla di script disattivati. Il problema non è Python: la guida agli ambienti virtuali Python (venv) in 5 minuti lo tratta in un avviso, e qui lo vedi da vicino. A bloccare Activate.ps1 è il criterio di esecuzione di PowerShell, che per i computer Windows «client» in Windows PowerShell 5.1 è Restricted; la soluzione è cambiarlo per il tuo utente o per la sola sessione, non spegnere la sicurezza di tutto il computer.

La risposta breve, quella indicata anche dalla documentazione di venv: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser. Se vuoi che valga solo per la finestra aperta, cambia CurrentUser in Process. Se non puoi cambiare nulla, per esempio su un PC aziendale, attivi la .venv dal Prompt dei comandi con activate.bat, oppure non l’attivi affatto.

ℹ️ Nota / Prerequisito operativo: questo articolo non nasce da una prova sul campo. Non avevo un computer Windows per provare i comandi, quindi tutto ciò che leggi è comportamento documentato: ho consultato la documentazione di Microsoft (PowerShell 5.1 e 7.6) e quella di Python sui venv, e indico di volta in volta la fonte. L’unico testo di errore che riporto è quello pubblicato da Microsoft.

Che cosa blocca PowerShell, e che cosa no

Secondo la pagina about_Execution_Policies di Microsoft, il criterio di esecuzione è una funzione di sicurezza che controlla a quali condizioni PowerShell carica i file di configurazione ed esegue gli script. Controlla gli script (.ps1), non i singoli comandi digitati a mano: con Restricted, per esempio, i comandi singoli funzionano, gli script no. Nella stessa pagina Microsoft precisa che non è un confine di sicurezza, ma una difesa a più livelli: aiuta a non eseguire per sbaglio uno script, non ferma chi vuole aggirarlo.

I valori che ti servono:

Due dettagli cambiano il quadro. Primo: nella documentazione di PowerShell 7.6 il valore predefinito per Windows è RemoteSigned, quindi l’errore è meno probabile in pwsh, il PowerShell 7. Secondo: Windows PowerShell 5.1 (powershell.exe) e PowerShell 7 (pwsh.exe) salvano il criterio in posti diversi e lo gestiscono separatamente, come scrive Microsoft nella pagina di Set-ExecutionPolicy: cambiarlo in uno non lo cambia nell’altro.

Il messaggio di errore

Ecco il testo che Microsoft pubblica nella guida «PowerShell 101», con uno script chiamato Get-TimeService.ps1, quando il criterio è Restricted:

.\Get-TimeService.ps1 : File C:\tmp\Get-TimeService.ps1 cannot be loaded
because running scripts is disabled on this system. For more information,
see about_Execution_Policies at
https:/go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ .\Get-TimeService.ps1
+ ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

Con Activate.ps1 mi aspetto la stessa forma, con il percorso della tua .venv al posto di quello dell’esempio, ma non ho una cattura reale con quel file e quindi non la mostro. La frase che conta è running scripts is disabled on this system: PowerShell sta dicendo che il criterio attuale non consente gli script.

Leggere la situazione con Get-ExecutionPolicy -List

Prima di cambiare qualcosa, guarda che cosa è impostato e dove:

Get-ExecutionPolicy -List

L’esempio di Microsoft mostra il formato dell’output:

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser    RemoteSigned
 LocalMachine       AllSigned

L’elenco è in ordine di precedenza. Se i criteri di gruppo (MachinePolicy, UserPolicy) non sono definiti, vince il primo scope non Undefined tra Process, CurrentUser e LocalMachine; nell’esempio di Microsoft il criterio effettivo è RemoteSigned, perché quello dell’utente ha la precedenza su quello del computer. Se tutti gli scope sono Undefined, il criterio effettivo sui Windows client in 5.1 è Restricted: è la situazione di un PC su cui nessuno ha cambiato il criterio.

Tre modi per attivare la .venv

1. Per il tuo utente, in modo permanente. È il comando indicato dalla documentazione di Python:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Il valore resta salvato nel registro per il tuo utente finché non lo cambi. Microsoft indica l’avvio di PowerShell come amministratore per lo scope LocalMachine, quello che vale per tutto il computer.

2. Per la sola finestra aperta. Con lo scope Process il criterio non viene salvato nel registro: vive nella sessione e sparisce alla chiusura.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process

3. Senza cambiare nulla. La documentazione di venv elenca per Windows anche l’attivazione dal Prompt dei comandi, che non passa da PowerShell:

.venv\Scripts\activate.bat

Dopo i primi due, l’attivazione in PowerShell è questa. Il prefisso .\ serve: Microsoft spiega che per eseguire uno script nella cartella corrente devi indicarne il percorso o usare il punto.

.\.venv\Scripts\Activate.ps1

RemoteSigned dovrebbe bastare perché Activate.ps1 lo crea Python sul tuo computer: non è uno script scaricato, e per i file scritti in locale quel criterio, come descrive Microsoft, non chiede la firma. La guida madre propone invece Bypass per la sola sessione: è un’alternativa più permissiva, perché non blocca nulla, nemmeno i file scaricati.

⚠️ Attenzione — non abbassare il criterio per tutto il computer: evita Unrestricted o Bypass con lo scope LocalMachine solo per far partire una .venv. Come scrive Microsoft, il criterio non è un confine di sicurezza, ma togliere anche questa barriera per una comodità è una cattiva idea.

Se Set-ExecutionPolicy non cambia nulla

Capita che il comando vada a buon fine e lo script resti bloccato. Microsoft lo descrive: un comando per cambiare il criterio può riuscire senza cambiare quello effettivo, per esempio quando un criterio di gruppo lo sovrascrive. Nell’esempio della sua documentazione la risposta è questa:

Set-ExecutionPolicy : PowerShell updated your local preference successfully, but the setting is overridden by the Group Policy applied to your system. Due to the override, your shell will retain its current effective execution policy of "AllSigned". Contact your Group Policy administrator for more information.

In questo caso Get-ExecutionPolicy -List mostra MachinePolicy o UserPolicy diversi da Undefined, e nessun comando locale li supera. Restano due strade, entrambe senza toccare il criterio: attivare la .venv dal Prompt dei comandi con activate.bat, oppure chiamare Python per percorso, come ricorda la documentazione di venv: non serve attivare l’ambiente se indichi il suo interprete.

.venv\Scripts\python.exe -m pip install tabulate

Con i criteri aziendali di mezzo, se ti serve davvero PowerShell, chiedi a chi gestisce il PC.

Errori tipici

• cannot be loaded because running scripts is disabled on this system → il criterio effettivo è Restricted (o Undefined in tutti gli scope, che per i Windows client in 5.1 equivale a Restricted) → usa Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser, o lo scope Process per una sola sessione.
• Il comando di modifica riesce, ma lo script resta bloccato → c’è uno scope con precedenza maggiore, oppure un criterio di gruppo → leggi Get-ExecutionPolicy -List dall’alto verso il basso; se MachinePolicy o UserPolicy sono impostati, passa a activate.bat o a python.exe per percorso.
• Hai cambiato il criterio, ma un’altra finestra dà ancora errore → powershell.exe e pwsh.exe hanno impostazioni separate → imposta il criterio nella shell che usi davvero per attivare la .venv.
• Ti sei spostato in .venv\Scripts e scrivi solo Activate.ps1 → per eseguire uno script della cartella corrente serve il prefisso .\ → scrivi .\Activate.ps1, oppure il percorso completo da fuori.
• Lo script è stato scaricato da internet e RemoteSigned lo blocca → Windows lo ha contrassegnato come proveniente dalla rete → verifica la fonte e sbloccalo con Unblock-File, come indicato da Microsoft. Non riguarda Activate.ps1, creato in locale.

Domande Frequenti (FAQ)

Devo aprire PowerShell come amministratore?

Per CurrentUser e Process la documentazione di Microsoft non lo richiede: lo richiede per lo scope LocalMachine, quello dell’intero computer. Per la .venv non ti serve.

La modifica resta dopo il riavvio?

Con CurrentUser e LocalMachine sì, perché sono salvati nel registro. Con Process no: vale per la sessione e sparisce alla chiusura.

Come torno indietro?

Imposta il criterio a Undefined nello stesso scope, per esempio Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser. Microsoft indica questo comando per rimuovere un criterio.

In PowerShell 7 (pwsh) l’errore compare lo stesso?

Meno probabile: nella documentazione di PowerShell 7.6 il valore predefinito per Windows è RemoteSigned. Il criterio può comunque essere imposto dai criteri di gruppo, e le impostazioni di powershell.exe non valgono per pwsh.exe.

Posso evitare del tutto PowerShell?

Sì: dal Prompt dei comandi la documentazione di venv indica .venv\Scripts\activate.bat. Oppure non attivi l’ambiente e chiami .venv\Scripts\python.exe per percorso.

Il criterio di esecuzione mi protegge dai virus?

Solo in parte. Microsoft lo definisce una difesa a più livelli, non un confine di sicurezza: impedisce di lanciare uno script per errore, ma si aggira scrivendo il contenuto a mano. Non sostituisce la prudenza su ciò che scarichi.

Dopo l’attivazione

Quando il prompt mostra (.venv), il resto del flusso è identico agli altri sistemi: torna agli ambienti virtuali Python (venv) in 5 minuti per installare i pacchetti, poi salva l’elenco con requirements.txt: congelare e ripristinare i pacchetti del venv. Se gestisci più progetti, più progetti, più .venv ti aiuta a non confondere gli ambienti. Per uno script Python già pronto e configurato su un PC Windows, è il tipo di lavoro che realizzo su richiesta.