When MakeCode extensions fail to load or the Arduino Library Manager hangs at zero percent, the school firewall is almost never blocking makecode.microbit.org or arduino.cc. Instead, the school’s enterprise content filter is silently dropping the dynamic, multi-host network requests running behind the scenes: raw code fetched from GitHub API endpoints, multi-hop content delivery network (CDN) redirects, or binary archives classified as software downloads.

To fix this, your school IT administrator does not need to compromise network security by opening the entire internet. They need a targeted whitelist that accounts for how browser-based compilers and microcontroller development environments actually pull code.

Why the Interface Loads but the Libraries Fail

Enterprise school firewalls—such as Fortinet FortiGate, Sophos, Smoothwall, or MikroTik gateways common in South African independent and state schools—rely on categorical filtering. These appliances categorise traffic based on domain reputation and MIME types. When a learner types the URL for an online IDE into Google Chrome, the main portal is categorised under Education, which is permitted.

The breakdown occurs the moment a learner adds an extension for an OLED display, a motor driver, or an ultrasonic sensor. Neither the Microsoft MakeCode engine nor the Arduino IDE bundles all third-party hardware drivers inside the base application. Instead, they fetch external packages dynamically over HTTPS from developer platforms. Those requests hit domains categorised under Software Downloads, Personal Storage, or Open Source Code Repositories, which default school firewall profiles aggressively restrict to prevent malware, unapproved software installation, and bandwidth exhaustion.

The MakeCode Dependency Pipeline

Microsoft MakeCode (whether running for BBC micro:bit, Arcade, or custom maker boards) is not a single website; it is an orchestrator that pulls together code from several independent hosts while compiling inside a web worker in the browser.

• Extension Discovery: When a learner searches for a package, MakeCode queries api.github.com to locate public repositories tagged for PXT (the Programming eXperience Toolkit). If the GitHub API is blocked or throttled by rate-limiting rules, search returns no results.
• Fetching Source Code: Once selected, the raw JavaScript and C++ driver code is downloaded from raw.githubusercontent.com. Many school filters treat this domain as unverified file storage (analogous to a file-sharing locker) and drop the connection, leaving the learner with a spinning wheel or a generic ‘Error loading package’ alert.
• Simulator and Cloud Compilers: Target-specific simulators and hardware targets are loaded dynamically from pxt.io and Microsoft-managed Azure endpoints (*.makecode.org). If these assets are blocked, the graphical workspace might appear, but the on-screen simulator will remain blank.

Arduino IDE: Archives, Redirects, and CLI Tools

The Arduino IDE (especially Arduino IDE 2.x, which is built on an Electron frontend running arduino-cli as a background daemon) faces a different network hurdle: archive downloads and redirect chains.

When you install a board definition (such as the ESP32, ESP8266, or SAMD core) or a community library, the tool follows this sequence:

1. It retrieves an index JSON file from an origin domain (for example, downloads.arduino.cc or a raw GitHub link specified in the Board Manager URLs).
2. The index file points to a compressed archive—typically a .zip, .tar.bz2, or .tar.gz file hosted on GitHub Releases.
3. GitHub Releases immediately issues an HTTP 302 redirect to an Amazon S3 storage bucket under objects.githubusercontent.com.

If the school network blocks executable file extensions or compressed archives from non-whitelisted domains, the download terminates abruptly. Furthermore, because arduino-cli handles these transactions via local background calls, it will not trigger the typical captive-portal browser login that school WiFi networks use to authenticate users.

SSL Inspection and the Certificate Problem

Many South African schools route traffic through transparent proxy servers running Deep Packet Inspection (DPI) to monitor learner web usage. For this to work, a custom Certificate Authority (CA) root certificate must be installed on every client machine. While managed Windows laptops distributed via a school management system might have this CA pre-installed, three common failure modes occur in a coding lab:

• BYOD Devices: Learners using personal laptops will see SSL handshake failures on every secure endpoint because their devices do not trust the school’s inspection certificate.
• Embedded CLI Tooling: The background command-line utilities used by robotics tools often use their own bundled certificate stores rather than reading the operating system’s trust store, resulting in connection resets.
• WebSockets: Real-time compilation and WebUSB/WebSerial debugging links can fail when passing through legacy HTTP-only caching proxies.

The IT Whitelist Checklist

Hand this concrete list to your school network administrator or IT department. Request that these domains and protocols be added to the bypass list for both the content filter and deep SSL inspection on the VLAN or IP subnet designated for the robotics lab or coding classroom:

In addition to domain whitelisting, the IT team should confirm that file extension filtering does not drop .json, .hex, .zip, .tar.gz, or .tar.bz2 streams originating from the domains above.

Practical Workarounds in Constrained Environments

If your school operates on an unbending centralised proxy—such as provincial education network connections where individual lab teachers cannot request local firewall changes—you must design around the network barrier:

• For MakeCode: Download the offline MakeCode app for micro:bit where an installer is available, or load extensions onto one ‘master’ project on an external connection (like a mobile hotspot), save the project as a .hex file, and have learners open that local file. MakeCode bundles already-imported extensions directly inside the .hex project file, so once imported, no network access is needed to use those blocks.
• For Arduino: Prepare a master installation of the Arduino IDE with all necessary boards (such as ESP32 or AVR cores) and classroom libraries pre-installed in the portable folder structure. Distribute this entire directory to lab computers via a USB flash drive or local network share, completely bypassing the in-class Board and Library Managers.

For institutions setting up dedicated hardware labs that require reliable device management, local toolchains, and firewall-compatible configurations across primary or secondary phases, our team supports infrastructure rollouts directly through Sheen Robotics School Services.

A modern coding classroom cannot function on a web-filtering policy built only for passive browsing. When IT administrators recognise that coding platforms behave like software deployment pipelines rather than static text pages, the fix is straightforward, specific, and permanent.