# OMP as a Company OS driver

Company OS owns company identity, run admission, policy, approvals, and the
ledger. OMP supplies the terminal interface and provider harness. An OMP MCP
profile is a connection convenience; it is not a Company OS run grant.

## Connect a manual OMP profile

Start the Company OS host, then authorize the current CLI session on an approved
device:

```bash
companyos login --company COMPANY_ID
companyos connect omp
```

`connect omp` verifies the selected company through the host, starts the CLI
bound MCP server for a live `company_os_health` and `company_os_get_company`
call, refreshes `~/.omp/agent/mcp.json`, and runs `omp plugin doctor`. The
profile contains a local executable path and no bearer, principal token, or
refresh token. The MCP server refreshes the CLI session on each call. If the
session expires, is revoked, or changes company, it refuses further calls.

This profile exposes only selected read tools. It cannot create or mutate
Company OS state. `--agent-dir PATH` targets another OMP agent directory. A
failed host, CLI, or MCP probe leaves the profile untouched. A doctor failure
reports an error after writing the profile.

## Governed work

`companyos chat` admits a terminal run through the Company OS host, then opens
the installed OMP TUI in the current directory. The broker gives OMP a private,
grant limited MCP profile and native action guard. `companyos chat --prompt TEXT`
runs one noninteractive turn; `companyos tui` remains the Zeron terminal
projection.

Each governed MCP callback sends its signed run grant to the host's
`capability-actions/authorize` route before the tool handler runs and settles
the exact action afterward. Ordinary API requests made by that callback also
carry the signed grant and allowed action ID. The host checks scope, expiry,
company, run status, grant issuance, revocation, and the matching unsettled
action receipt before dispatch. Model steps and linked tool results are written
to the run execution ledger. The local JSONL audit remains supplementary.
A manual `omp` session through `companyos connect omp` remains read only and
does not create an accountable run.

Live installed OMP evidence on 2026-10-03: a `company_os_health` call in run
`7da722ac-a140-4ae5-8fce-289dec605369` has host authorization and settlement
receipts in `governance/events`. A later attempt to create a task through native
shell in run `fca8efc0-d366-4422-a5b3-101db9126ca6` was denied before the
shell effect and produced pending approval request
`a2b31fff-3383-4217-beb0-5f07b1bbe7be`. A subsequent host task-list read
returned 63 tasks and no `Approval gate probe` task. These prove the host action boundary;
they do not prove model-step receipts or turn receipt parity. The read run's
`execution-events` stream was empty, and Zeron reported HTTP 401 during its
settlement. The terminal client must not advertise a complete governed receipt
until a fresh installed run returns one from the host.