BoundaryML/baml · error · VmBamlError

access error: {message}

Error message

access error: {message}

What it means

An error value from the BAML standard library, mapping to the `baml.errors.AccessError` class. It represents a permission/access failure when a stdlib operation attempts to use a resource the caller is not permitted to access — the access was checked and denied, distinct from the resource not existing.

Source

Thrown at baml_language/crates/bex_vm_types/src/errors.rs:131

    #[error("invalid argument: {message}")]
    InvalidArgument { message: String },

    #[error("parse error: {message}")]
    ParseError { message: String },

    #[error("I/O error: {message}")]
    Io { message: String },

    #[error("timeout: {message}")]
    Timeout {
        message: String,
        duration_ms: Option<i64>,
    },

    #[error("unsupported: {message}")]
    Unsupported { message: String },

    #[error("access error: {message}")]
    AccessError { message: String },

    #[error("render prompt: {message}")]
    RenderPrompt { message: String },

    #[error("LLM client error: {message}")]
    LlmClient { message: String },

    /// An error value from the host language that has no direct BAML
    /// representation. The `handle` is the load-bearing field — it
    /// references the original host exception object via the
    /// process-global host-value table, so the originating runtime can
    /// recover the exact native exception on round-trip. The
    /// `class_name` / `message` / `language` / `traceback` fields are
    /// purely metadata for debugging, logging, and user-facing
    /// formatting — they do not participate in error matching or
    /// rehydration.
    ///

View on GitHub (pinned to bd85ce9dee)

Solutions

  1. Fix permissions on the resource (chmod/chown) or run the process with an identity that has access.
  2. Keep resource paths within the runtime's allowed roots/sandbox policy.
  3. Catch `baml.errors.AccessError` and fall back to an accessible resource or a clear user-facing message.
  4. Verify the deployment environment's mounts and user accounts match development assumptions.

Example fix

// before
let cfg = fs.read("/etc/baml/secrets.env"); // may be denied
// after
let cfg = match (try fs.read("/etc/baml/secrets.env")) {
  ok(v) => v,
  err(e: baml.errors.AccessError) => fs.read("./local.env")
};
Defensive patterns

Strategy: try-catch

Validate before calling

// BAML: verify access before reading
if !fs.can_read(path) {
  return err("no permission for: " + path);
}

Try / catch

try {
  let data = fs.read(path);
} catch e: baml.errors.AccessError {
  return accessible_alternative() ?? fail_with_message(e.message);
}

Prevention

When it happens

Trigger: Calling stdlib file/host operations on a resource the runtime lacks permission for: unreadable file, restricted path, sandbox denying access to a resource, or OS permission errors (EACCES-like) surfaced through the host.

Common situations: Reading files outside an allowed sandbox root; running containers as a non-root user without volume permissions; deploying to environments where the working files are owned by another user; overly restrictive runtime policies.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors


AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12). Data as JSON: /api/errors/966eea591280d763. Report an issue: GitHub.