Safety: avoid disabling macOS Wi-Fi network service during troubleshooting

[ascendho]

Summary

Codex should avoid disabling core macOS network services during connectivity troubleshooting, or require a much stronger warning/confirmation before doing so.

During a troubleshooting session for a Mac Wi-Fi / Personal Hotspot connection problem, Codex executed:

networksetup -setnetworkserviceenabled Wi-Fi off

This disabled the macOS Wi-Fi network service and caused Network Settings to show Wi-Fi not configured. The service was later re-enabled with:

networksetup -setnetworkserviceenabled Wi-Fi on

The issue is not the original hotspot failure. The issue is that disabling the entire Wi-Fi network service was treated as a normal diagnostic step. This is materially different from toggling the Wi-Fi radio with networksetup -setairportpower.

Why this is risky

For users who are not comfortable with macOS network settings, this can make the computer appear broken or unable to connect to the internet. A user might lose work time, be unable to recover without another device, or assume the Mac needs repair.

This is also a self-defeating operation for an agent like Codex/ChatGPT: if the user's active internet connection depends on Wi-Fi, disabling the Wi-Fi network service can cut off the very network connection that Codex needs in order to continue assisting or recover from the mistake.

Expected behavior

• Prefer read-only diagnostics and user-guided UI steps before changing system network configuration.
• Clearly distinguish toggling Wi-Fi radio from disabling the Wi-Fi network service.
• Avoid commands such as networksetup -setnetworkserviceenabled Wi-Fi off unless absolutely necessary.
• If such a command is suggested, require an explicit high-risk confirmation that explains it may make Wi-Fi appear unconfigured or unavailable.
• Avoid network-disabling actions when the user's current connection may depend on Wi-Fi.

Suggested guardrail

Treat disabling, deleting, or reconfiguring core network services as a high-risk local system operation, separate from simple connectivity troubleshooting.

[ascendho]

Additional note on security reporting scope:

I noticed SECURITY.md points users to the Bugcrowd program for validated vulnerabilities. I am not sure whether this should be handled as a traditional security vulnerability or as a Codex safety/approval guardrail issue, but the impact resembles a local self-DoS: Codex can disable the user's active network path and lose the ability to help recover.

This seems especially relevant for agentic local execution because the action can break the communication channel the agent itself relies on to continue assisting the user.