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
- Fix permissions on the resource (chmod/chown) or run the process with an identity that has access.
- Keep resource paths within the runtime's allowed roots/sandbox policy.
- Catch `baml.errors.AccessError` and fall back to an accessible resource or a clear user-facing message.
- 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
- Keep application files within the sandbox/allowed roots.
- Set correct ownership/permissions before deployment.
- Run containers with a user that owns or can read the mounted volumes.
- Review sandbox policies when adding new file or host resource accesses.
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
- failed to install {} into {}
- I/O error: {message}
- ErrCacheDir
- failed create destination %s: %w
- IO error: {0}
AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12).
Data as JSON: /api/errors/966eea591280d763.
Report an issue: GitHub.