glas-harness

glas-harness is the primary execution-layer abstraction for governed agent work. Consumers select a versioned Glas profile; Glas resolves the concrete rein, model route, sandbox profile, tool policy, and limits, runs the outer lifecycle, and returns one normalized evidence envelope.

The consumer contract does not name a Python rein class or provider CLI:

assignment / channel / activity
  -> ExecutionRequest(harness_profile_ref=...)
  -> Glas profile resolution
  -> rein + model + sandbox + tool policy
  -> normalized ExecutionEvidence

Profiles

List and validate every committed executable profile:

glas-harness profiles
glas-harness profiles --json

Current constellations include:

• harness.agent-dev-local@1.0.0: rein-aharness, Claude Code model route, local bwrap sandbox.
• harness.agent-dev-openweights-local@1.0.0: rein-openweights, OpenRouter open-weight route, local bwrap sandbox.
• harness.agent-dev@1.0.0: rein-aharness, remote agent-dev sandbox.

Run a task through an explicit profile:

glas-harness run \
  --harness-profile harness.agent-dev-local@1.0.0 \
  --repo /absolute/path/to/repo \
  --title "Bounded change" \
  --description "Make the requested change and commit it"

There is no governed default rein, model, sandbox, or tool profile. Unknown, disabled, incompatible, and ambiguous selections are refused before sandbox creation.

After creation, execution uses only the reachability-derived sandbox workspace: same-host namespaces are entered with nsenter, while remote workspaces are reached over SSH. The source checkout is provisioning input, not a rein workdir.

See SCOPE.md, INTENT.md, docs/execution-profiles.md, and docs/harness-contract.md.

Development

uv run pytest -q