Can QBCore scripts work on Qbox?
Many QBCore scripts run on Qbox because qbx_core ships a qb-core compatibility layer, but "runs" and "is built for Qbox" are different claims. Scripts that call qb-core's exports directly usually work through the shim; scripts that assume job.grade is a plain number can break, because Qbox represents grade as a table with a `.level` field. Escrowed QBCore scripts are the riskiest case, since you cannot patch what the shim doesn't cover.
In one lineMost QBCore scripts run on Qbox through qbx_core's built-in qb-core compatibility shim, but native Qbox support and shimmed QBCore compatibility are different levels of support with different failure modes.
The longer answer.
Qbox is a fork of QBCore, so it ships a compatibility layer that answers to the qb-core resource name and export signature — this is why a large share of existing QBCore scripts install and appear to work on a Qbox server without modification. The shim exists for exactly this purpose: to let servers migrate without an immediate rewrite of every purchased resource.
The shim doesn't make Qbox behave identically to QBCore internally, and the gaps show up in specific, predictable places. The most common: QBCore-era code treating job/gang grade as a plain number, which fails or misbehaves against Qbox's grade table with a `.level` field; code calling qb-target instead of the ox_target most Qbox servers actually run; and multi-job or multi-gang states that QBCore never expected a player to be in.
Escrow changes the stakes rather than the odds: an open QBCore script that breaks on Qbox can be patched by whoever runs the server; an escrowed one cannot, and the fix depends entirely on the vendor choosing to ship a Qbox-native update. That's why the practical question before buying isn't "does it run on Qbox" but "is Qbox a tested target or an inherited compatibility branch," and whether you could fix it yourself if the answer turns out to be the latter.
QBCore vs Qbox — what actually differs for a migrating script
| Aspect | QBCore | Qbox |
|---|---|---|
| Core export | exports['qb-core']:GetCoreObject() | exports.qbx_core:GetPlayer(source) |
| Job/gang grade shape | Typically a plain number | A table with a .level field |
| Multi-job/gang support | Not assumed by most legacy code | Native support expected |
| World interactions | qb-target | ox_target |
| UI and callbacks | Framework-specific menus and callbacks | ox_lib callbacks and UI primitives |
| Compatibility path | Native | Runs QBCore code via a qb-core shim, or natively against qbx_core |
The checklist.
- 01Confirm whether the script calls qb-core's export directly or through a framework bridge — direct calls are what the shim has to intercept.
- 02Grep any open source for job.grade or gang.grade compared as a plain number; Qbox needs `.level` read from that table.
- 03Check whether world interactions use qb-target; Qbox servers typically run ox_target, though a compatibility layer covers many cases.
- 04Verify the inventory system — Qbox commonly runs ox_inventory, and item metadata handling differs from qb-inventory.
- 05Ask whether the vendor has tested and dated a Qbox-specific run, or is relying on the shim without verification.
- 06If the script is escrowed, treat any Qbox compatibility claim as a vendor promise you cannot independently verify or fix.
Where this is covered in full.
People asking this also ask.
Where to go from here.
Published 2026-09-02 · Last reviewed 2026-09-02 · Vice Drip · All answers