xtekky/gpt4free · error · ImportError

Relative imports are not allowed inside a .pa.py sandbox.

Error message

Relative imports are not allowed inside a .pa.py sandbox.

What it means

Thrown by the sandbox's restricted __import__ replacement (_restricted_import in pa_provider.py) when level > 0, i.e. the module uses a relative import ('from . import sibling', 'from ..pkg import x'). Sandboxed .pa.py modules are compiled with __package__ = "" and loaded standalone, so Python's relative-import machinery has no package context to resolve against — the sandbox rejects it up front with this explicit ImportError.

Source

Thrown at g4f/mcp/pa_provider.py:446

            "g4f.Provider",
            "g4f.config",
        }
    )

    # Explicit allowlist for g4f sub-paths that would otherwise be blocked.
    # Checked *before* the blocklist so these entries take priority.
    _ALLOWED_G4F_SUBPATHS: FrozenSet[str] = frozenset(
        {
            "g4f.Provider.helper",
            "g4f.Provider.base_provider",
            "g4f.Provider.template",
            "g4f.typing",
        }
    )

    def _restricted_import(name, globals=None, locals=None, fromlist=(), level=0):
        if level > 0:
            raise ImportError(
                "Relative imports are not allowed inside a .pa.py sandbox."
            )
        base = name.split(".")[0]
        # Return the restricted os shim instead of the real os module.
        if base == "os":
            _os_shim = _make_restricted_os()
            if name == "os":
                return _os_shim
            # Handle "os.submodule" — try to resolve from the shim
            obj = _os_shim
            for part in name.split(".")[1:]:
                obj = getattr(obj, part, None)
                if obj is None:
                    raise ImportError(
                        f"'{name}' is not available in the restricted os shim."
                    )
            return obj
        if base not in allowed:

View on GitHub (pinned to 973504e177)

Solutions

1. Rewrite relative imports as absolute ones using allowed top-level modules: 'from helpers import run' only works if helpers is loadable/approved; otherwise inline the needed code or use supported g4f subpaths.
2. Keep each .pa.py self-contained — the sandbox is designed for standalone tool modules.
3. If shared code is required, put it in an allowed installed package and import it absolutely (e.g. from g4f.Provider import helper).

Example fix

// before (module.pa.py)
from .utils import parse

// after
def parse(x):
    ...  # inlined, or: from an allowed absolute module

import ast

def has_relative_imports(source: str) -> bool:
    tree = ast.parse(source)
    return any(
        isinstance(n, ast.ImportFrom) and n.level > 0
        for n in ast.walk(tree)
    )

try:
    module = load_workspace_module(name, source_path)
except ImportError as e:
    if "Relative imports are not allowed" in str(e):
        reject_upload("rewrite relative imports as absolute or inline the code")
    raise

When it happens

Trigger: A .pa.py file containing 'from .helpers import run' or 'from ..tools import api'; usually code lifted from a real package where the module lived inside a package tree.

Common situations: Copying a module out of a package into the sandbox without rewriting its imports; refactoring shared utilities into sibling files and importing them relatively.

Related errors

• Syntax error in workspace module '{name}' ({source_path}):\n
• Failed to load workspace module '{name}' ({source_path}):\n{
• Cannot find submodule '{name}' in workspace module '{base}'.
• '{name}' is not available in the restricted os shim.
• Import of '{name}' is not allowed in safe execution mode.\nA

AI-assisted analysis of xtekky/gpt4free@973504e177 (2026-08-14). Data as JSON: /api/errors/9f2a5dee8051fb28. Report an issue: GitHub.