SkyBlue997/enableMacosAI: a kext that spoofs RegionCode to LL/A on China-market Macs

What the CH/A region gate actually blocks

On a China-market Mac, MGGetStringAnswer("RegionCode") returns CH, and the README states that this is the root cause of Apple Intelligence being switched off. The value is not read from a cached plist. According to the README, it comes live from the region-info property on IOPlatformExpertDevice in the IORegistry, and macOS 27's eligibilityd recomputes eligibility from SwiftData in real time, which is why the older approaches of editing a plist or locking it with uchg stopped working. The audience here is narrow: people running Apple Silicon hardware bought in China who want the on-device model, and who are comfortable disabling kext signature checking. It is not a tool for Intel Macs, and the README frames the whole thing as solving the eligibility layer, explicitly not Apple's server-side gate or the network path to Private Cloud Compute.

How the RegionSpoof kext rewrites region-info at the source

The mechanism is a single IOKit personality. src/Info.plist declares an IOKitPersonalities entry matching IOPlatformExpertDevice, and src/RegionSpoof.cpp implements an IOService whose start() calls setProperty("region-info", "LL/A") together with setProperty("country-of-origin", "USA"). Because the property is changed on the platform expert device itself rather than injected into individual processes, every process on the system reads the US value from the same origin. The README's argument is that eligibility, model delivery and the front-end UI then follow without per-process injection. src/kmod_info.c supplies the _kmod_info symbol the linker needs, and RegionSpoof.kext/ is the prebuilt arm64e bundle with an ad-hoc signature. A LaunchDaemon, com.local.regionkext.plist, calls region-kext-load.sh early at boot to load the kext and refresh the Apple Intelligence daemons. Note the scope: the kext sets region and country-of-origin, and nothing else. GREYMATTER eligibility, per the README, depends on roughly ten inputs.

Installing with install.sh and confirming the region flipped

The recommended path is the one-shot installer. It checks SIP and Apple Silicon, removes the amfi_get_out_of_my_way boot-arg that the README says kills PCC, installs the kext, configures autostart, loads it and refreshes the Apple Intelligence daemons. The first run tells you to click Allow once in System Settings, Privacy & Security, then reboot.

sudo ./install.sh

Before that, the README's precondition is to boot into recovery and run the following, which disables only kext signature checking and keeps more SIP protection than a full disable. The script recognises both this state and a full csrutil disable.

csrutil enable --without kext

After the reboot, verify the property. The README says region-info should read 0x4c4c2f41, which is LL/A.

ioreg -ard1 -c IOPlatformExpertDevice | plutil -p - | grep region-info

Then check the eligibility answer, which should be 4.

sudo /usr/libexec/PlistBuddy -c 'Print :OS_ELIGIBILITY_DOMAIN_GREYMATTER:os_eligibility_answer_t' \
  /private/var/db/eligibilityd/eligibility.plist

If something is off, sudo ./install.sh status prints SIP, AMFI, region, kext and eligibility in one pass, and sudo ./install.sh diagnose emits a single plain-text block the README asks you to paste into an issue.

GREYMATTER still 2 after a successful region spoof

This is the failure mode the README spends the most words on, and it is the one most likely to be mistaken for a broken install. Region is one of roughly ten eligibility inputs. If ioreg shows LL/A and the kext is loaded but the GREYMATTER answer is 2, the README says the usual culprits are the Apple account media and purchases region, which must not be China, and the language pairing, where system language must equal Siri language and be a supported one. The most reliable setting is English (US) for both. There is a second, separate input called COUNTRY_LOCATION, judged by countryd from location services, nearby Wi-Fi and IP. The README states plainly that this project does not handle it. The community workarounds it lists, using wloc plus killall locationd, editing countryCodeCache.plist and locking it with chflags uchg, or a clean reinstall followed immediately by the script, are all marked as unverified by the project and taken at your own risk. Editing the numbers inside eligibility.plist directly does not work, because eligibilityd recomputes. Treat any single input reading 2 as a hint, not a diagnosis; the domain answer is what counts.

Private Cloud Compute needs a TUN proxy, not a region code

The README is direct that a working on-device model does not prove PCC works, and warns against reading GREYMATTER=4 as a promise of cloud availability. PCC goes through Apple's private relay, and ordinary system HTTP proxies do not touch it. The combination the README reports as repeatedly confirmed by users is TUN or enhanced mode with global routing; Surge users are told to enable enhanced mode only and to leave system proxy off. The proxy has to be up immediately after network comes online, before signing in and before using AI, and the node needs to be stable, because a node that fluctuates shows up as errors that come and go. When it fails, the instruction is to stop clicking and run the read-only classifier instead, since each failure can trigger backend rate limiting; 32033 is described as rate limiting, to be retried after a wait. There is also a server-side component outside anyone's control: the README notes the fence moved on 8/13 and tightened again on 8/14, so intermittent PCC is not necessarily a local fault.

The pcc subcommand and what it will not tell you

pcc-diagnose.sh is a read-only classifier for the last 30 minutes of PCC, relay and token state, and the README states it does not output request contents. It is driven through the installer rather than run directly, and the window is configurable.

sudo ./install.sh pcc
sudo ./install.sh pcc --since 2h

There is an offline fixture test at tests/test-pcc-diagnose.sh, which is a reasonable sign that the classifier's categories are pinned down rather than eyeballed. What the classifier cannot do is fix anything. It sorts a failure into a category and points you at the matching troubleshooting entry. If your problem is that the proxy was never configured for Apple's relay domains, no amount of classification changes that. The value of the tool is mostly in stopping the retry loop, which the README treats as an active harm.

Keeping a Chinese UI without losing the new Siri

The perapp-zh/ directory is the part of this repository that is easiest to misread. Eligibility reads the user-global AppleLanguages value and the Siri language, and the README says the new Siri's language allowlist is English-only, verified instruction by instruction in eligibilityd. There is no way to show Chinese to the detector while running an English UI. So perapp-zh/ inverts the approach: keep the global language English and write Chinese into each app's own preference domain, which is equivalent to adding apps one at a time under Language & Region. eligibilityd does not read those domains. System Settings, which the README says Apple hard-excludes, is launched by a resident agent with an -AppleLanguages argument, keeping a single Dock icon and preserving deep links. Every change is recorded and revertible, and the tool must not be run with sudo because it edits the current user's preferences.

cd perapp-zh
./perapp-zh.sh dry-run
./perapp-zh.sh all
./perapp-zh.sh status
./perapp-zh.sh revert

Run dry-run first; it only counts and changes nothing. The all target covers Finder, Dock, built-in apps, widgets and System Settings, while third-party is kept as a separate, wider scope.

Alternatives, and what this costs you

The obvious alternative is not to spoof at all. If you can change your Apple account media region and set system and Siri language to English (US), you satisfy two of the inputs without touching SIP or loading a kext. That path leaves the region input unmet, so on a China-market machine it will not be enough on its own, but it is the correct first step regardless, and it is reversible in System Settings. The other alternative, which the README explicitly rules out as obsolete on macOS 27, is editing eligibility.plist or locking it with uchg; eligibilityd recomputes from SwiftData, so those edits do not hold. A third option is a clean reinstall of macOS followed immediately by the install script, which the README lists as a community-reported way to avoid leaving Wi-Fi traces for countryd. Weigh the cost honestly. You are disabling kext signature checking, which is a smaller hole than a full csrutil disable but still a hole, and you are loading third-party code into the kernel before the rest of the system comes up. The kext is ad-hoc signed, and the README notes that a macOS version too new or too old may fail verification or KPI matching, in which case you rebuild from source using BUILD.md. There are no releases retrieved for this repository, so the prebuilt bundle in the tree is what you get. The licence is not stated anywhere in the repository, which means you should establish the terms before redistributing the kext or shipping it inside anything.

Editorial conclusion

Adopt it if you have an Apple Silicon Mac, you are willing to run csrutil enable --without kext in recovery mode, and you accept that GREYMATTER needs roughly ten inputs to line up, of which this project supplies one. Do not adopt it if you expect a single command to deliver working Private Cloud Compute, or if you cannot change your Apple account media region and language settings, because the README states the kext alone will leave GREYMATTER at 2. Verify first that ioreg reports region-info as 0x4c4c2f41 and that PlistBuddy prints OS_ELIGIBILITY_DOMAIN_GREYMATTER:os_eligibility_answer_t as 4; if the region is LL/A and the answer is still 2, the remaining inputs are account region or language, not the kext.

Frequently asked questions

Official sources

1. Issues
2. README
3. SkyBlue997/enableMacosAI on GitHub