Platform support

DataMind Oda ships small native pieces behind its command confinement and the write locking of its session logs. This page lists which systems carry those pieces, how the confinement and locking behave, and how to use them from your own programs.

The desktop app and the SDK packages have their own system requirements: see Install and sign in for the app, and Oda SDK: Python reference for the Python packages.

Which systems carry the native pieces

• The pieces are published per system, and an installation takes only the part that matches the running system.
• A system with no published piece is refused, not approximated: nothing falls back to another system's build, and nothing compiles during installation. A missing piece fails loudly instead of being built on your machine.
• The launcher is the Linux piece of Oda's command confinement, so only Linux systems carry it. For how commands run inside a chat, and what a denial looks like, see Command environment and containment.

How commands are confined on Linux

On Linux, a small executable confines a command to the paths you grant and then starts it. It uses Landlock, the Linux kernel's confinement mechanism, and the restrictions cover the command and every process it starts.

• Everything is an allow-list: whatever is not granted is denied. --ro <path> grants read and execute under a path, and --rw <path> grants full access under a path.
• The launcher can probe the kernel and reports one of three verdicts:
  • full, with the probe line landlock: fully enforced: the kernel enforces everything the launcher asks of it.
  • partial, with the probe line landlock: partially enforced (older ABI): the kernel enforces an older version of the mechanism, so the access types added later are not covered. Runs continue, and each one prints landlock-run: partial enforcement (older Landlock ABI) on standard error.
  • unusable: the launcher cannot enforce anything. This verdict merges three causes: a kernel without the mechanism, a disabled security module, or a missing binary. The answer is the same in each case: do not trust this launcher to confine the command.
• The probe is a real enforcement attempt, not a version check: it restricts a short-lived process with a maximal set of rules, so a kernel that has the calls but refuses enforcement still reports unusable.
• Fail closed: every launcher-level failure ends with exit code 125 and the wrapped command is not run. That covers a bad invocation, a kernel that cannot enforce, a grant path that cannot be opened, and a failed start. The kernel refusal reads landlock is not enforced by this kernel (ABI unsupported or disabled).
• Code 125 alone is not proof of a launcher failure: a wrapped command may use 125 for its own failures. Treat 125 as a launcher failure only when a fatal line that starts with landlock-run: appears on standard error.

Locking session logs

While a session log is open for writing, Oda holds an exclusive lock on it so that only one writer appends at a time. The messages you see when a chat is already being written are in Session log problems.

• The attempt is exclusive and non-blocking. Contention is refused straight away with EAGAIN or EWOULDBLOCK, so a busy file surfaces as a refusal, never as a stall. A failed attempt names its code, for example EAGAIN: flock failed.
• It is an advisory lock, not an I/O permission. It coordinates writers that take it, and another program can still read or write the file.
• The lock is released when the last descriptor for that open file is closed, including when the process holding it exits or is killed. There is no stale-lock timeout.
• Closing one descriptor does not release the lock while another descriptor for the same open file remains.
• There is no blocking wait and no shared lock: the only lock on offer is exclusive and non-blocking.
• The locking piece loads lazily, on the first lock attempt; a missing piece is a refused attempt, not a broken import.
• On a system with no locking build, the attempt is refused with flock is not supported on <platform>-<arch>.

Use the native pieces in your own programs

• Ask for the launcher's path on this system, and build its grant arguments: read-only grants are placed before read-write grants, and the order you give them is kept.
• Whether confinement works is decided by the probe, not by whether a path exists. The probe waits up to two seconds by default, and a hang counts as unusable.
• The locking piece offers one call: an exclusive, non-blocking lock attempt on a file descriptor, returned as a promise.
• Importing either piece loads no native code; the locking piece loads only when you first lock a file.
• No environment variable changes which binary confines a process: the launcher takes its instructions only from its own arguments.

Questions, answered

What happens on a system with no published native piece?

Confinement and locking are refused rather than approximated: the launcher's probe reports unusable, lock attempts are refused, and nothing falls back to another system's build. Nothing compiles during installation either, so a missing piece surfaces as a refusal.

Why is there no confinement launcher on macOS or Windows?

The launcher is built on a Linux kernel mechanism, so it ships for Linux systems only. On macOS the pieces provide locking only, and on Windows Oda uses its own locking implementation.

A confined command exited with 125. Did the launcher fail?

Maybe. 125 is the launcher's failure code, but a wrapped command may also exit 125 on its own. Check standard error: a launcher failure always prints a fatal line that starts with landlock-run: , and in that case the wrapped command was not run.

Will a command run when the kernel cannot enforce the restrictions?

No. The launcher fails closed: when it cannot enforce, it exits with code 125 and the wrapped command is not run, with the refusal landlock is not enforced by this kernel (ABI unsupported or disabled) on standard error.

What does partial enforcement change for a run?

The kernel enforces an older version of the mechanism, so the access types added later are not covered. Runs continue, and each prints landlock-run: partial enforcement (older Landlock ABI) on standard error. Where everything must be governed, run on a machine whose probe reports full.

Is the file lock a protection against other programs?

No. It is an advisory lock: it coordinates writers that take it, and another program can still read or write the file directly. It is not a way to protect a file from other programs.

What releases a session lock?

Closing the last descriptor for that open file, including when the process holding it exits or is killed. There is no stale-lock timeout, and closing one descriptor does not release the lock while another still refers to the same open file.

What happens when there is no locking build for my system?

The attempt is refused with flock is not supported on <platform>-<arch>. Nothing compiles during installation, and a lock is never granted silently, so the failure is a refused attempt rather than a broken import.

Can an environment variable change which binary confines a process?

No, by design. The launcher takes its instructions only from its own arguments, and nothing the calling process exports changes what is confined.

How do I know whether confinement works on this machine?

Run the probe. It is the single availability signal: it waits up to two seconds for an answer, and a hang counts as unusable. The presence of a launcher path is deliberately not checked; the probe decides.