The host exposes a named authority such as project filesystem access or approved HTTP origins.
CodeTether language runtime
TetherScript
A small scripting language for Rust systems that need reviewable plugins, constrained agent behavior, and a runtime model built around explicit authority.
Why it exists
Dynamic extension points without giving up control of the host.
Rust products often need behavior that changes faster than the release cycle: policy checks, customer workflows, repository automation, validators, guards, and agent-generated helpers. TetherScript gives those behaviors a tight language surface and makes the host boundary part of the program.
01 / The pressure
Every mature system grows a scripting need.
A product starts with clean Rust APIs. Then customers ask for custom rules. Internal teams want small automations. Agents begin drafting changes. The easy answer is to add callbacks, config files, or a general scripting runtime.
TetherScript exists for the point where extension is necessary but ambient power is not acceptable.
02 / The boundary
Authority is passed in, not discovered globally.
Scripts can hand smaller authority to helpers instead of sharing the original grant everywhere.
A parent authority can cut off children when a workflow ends or a policy fails.
Reviewers can see where host power enters the script instead of hunting for hidden standard-library access.
03 / The language
Rust-shaped control flow with a dynamic edit loop.
fn validate(change) {
if change.files.len() == 0 {
return err("no files changed")
}
if change.diff.contains("unsafe") {
return err("unsafe needs explicit review")
}
return ok("ship it")
}
04 / Ownership
Runtime checks catch the mistakes dynamic languages usually hide.
TetherScript keeps values flexible but makes moves visible. Scalars are copied, heap values move, and use-after-move is reported as a runtime error instead of turning into a later state bug.
let files = ["a.rs", "b.rs"]
let queue = move files
queue.push("release.rs")
files.len()
// runtime error: value `files` was moved
05 / Runtime model
Start with the reference interpreter. Graduate to the VM.
Interpreter
Easy to inspect, instrument, and embed while the language surface is still moving.
Bytecode VM
Compiles the same syntax into a compact stack machine for production workloads.
LSP
Editor diagnostics reuse the lexer and parser that run real scripts.
Denied authority
A script that reaches outside its grants fails at the boundary, before ambient access can become a production incident.
06 / Agent workflows
Let agents write behavior without letting them own the host.
-
Draft
An agent proposes a script for a policy, plugin hook, migration guard, or repository task.
-
Review
Humans inspect a small script surface and the explicit capabilities the host grants it.
-
Run
The host executes the script with bounded authority and a runtime built for clear failures.
07 / Embedding
A Rust host decides what the script world can touch.
let source = std::fs::read_to_string("examples/policy.tether")?;
let tokens = Lexer::new(&source).tokenize()?;
let program = Parser::new(tokens).parse_program()?;
let mut interp = Interpreter::new();
interp.grant("fs", FsAuthority::new(root));
interp.run(&program)?;
08 / Operational fit
Small enough for tooling, explicit enough for production.
09 / Quickstart
Run a script, inspect it, then embed it.
cargo build --release
./target/release/tetherscript examples/hello.kl
./target/release/tetherscript --vm examples/hello.kl
./target/release/tetherscript --grant-fs . examples/policy.tether
./target/release/tetherscript --lsp
10 / Failure
Denied authority is a first-class runtime outcome.
The host grants a script exactly the authority it can use. If a workflow only receives read access to ./policy, a read from /etc/passwd does not become an accidental host call. It becomes a reviewable failure.
let policy = fs.read("./policy/release.toml")
let secret = fs.read("/etc/passwd")
// error[E_CAPABILITY_DENIED]
// fs.read denied: path is outside grant "./policy"
11 / Roadmap
Sharper guarantees, not a sprawling language.
- Next release Richer diagnostics for Result and capability failures.
- Next release VM local-slot optimization for hot scripts.
- This quarter Stronger mutability and aliasing checks.
- This quarter Module boundaries for larger plugin sets.
- Exploring More host capabilities with explicit attenuation.
For systems that invite extension