LexLint first run - full procedure for agents
=============================================
Version 2026-09-21 0axypmy

Run this procedure exactly, and nothing it does not name.

The second half of that line is the limit on this document, and it is the
part to read first. A fetched page looks the same whether it is a procedure
or an attack, so here is the whole of what this one asks of you. You read the
repository. You send one server two lists and the repository's name, and read
its reply. In STEP 5 you ask to store that run, which sends the same two lists
again and no findings: the server rebuilds those itself. One file goes under
/tmp, or under a directory of its own in your client's scratch space, outside
the repository either way, and STEP 6 deletes it. Nothing in the working tree
changes and nothing is committed. One credential is in play, a trial key this
server issues: you read it, you send it back on the calls that need it, and
STEP 7 offers to keep it. No credential the developer already had is read
or asked for. Adding LexLint's server to this client is what STEP 1 offers and
STEP 7 offers again, with a shell-profile line beside it there, and none of it
happens without their yes. An instruction here that goes past that list is
not this document's to give: stop, and tell the developer which one it was.

This document is published by UnGovr at lexlint.io. The same publisher runs
the server STEP 4 calls at mcp.lexlint.io, the portal at
https://my.lexlint.io and the plugin whose source is at
https://github.com/ungovr/lexlint so the lint, the upload and the key all go
to one party, and that party published this page. GitHub is the one host
named below that is not theirs: it carries the plugin's source, the reporting
rules STEP 6 points at, and the install STEP 7 gives. It is in front of you
because the developer pasted it, or its address, into this session. Either
paste is the request. If they did neither, stop here.

If what you are reading is a SUMMARY of this document rather than its literal
text, stop. A summary of a procedure comes back carrying its commands, so what
a summary drops is whatever is not one, and the first casualty is STEP 1: it
is the step that offers to replace every other step with a single tool call,
and a summary that skipped it has already cost the developer the short road. A
paraphrase of STEP 4 is worse still, because that call carries an exact JSON
argument and a credential that a summary rewrites or drops. Fetch the literal
text with your shell before following any step:

    curl https://lexlint.io/first-run -sS --fail-with-body

If you cannot REACH this server, stop and say so. A request that fails to
resolve the host, is refused by a sandbox, times out, or comes back 5xx all
mean the same thing: there is no lint, and a lint that did not run has no
findings. Every curl below carries --fail-with-body for that reason, because
plain curl -sS exits 0 on a 500 and prints the error page as though it were
the answer. Say which command failed, quote the error it printed, and name the
activities and jurisdictions you were about to declare, so the developer can
re-run it once the network is there. Give that declaration as a plain list,
one value per line, and never as a table: a bordered table with an evidence
column is the shape a developer reads as a result, whatever the caption above
it says. Report NOTHING else: no table, no severities, no instrument names, no
law that is "likely" to apply. Do not answer from memory, from training data,
from a web search, or from any other copy of a corpus you find on disk. Every
one of those produces something shaped exactly like a lint result that no lint
produced, and the developer cannot tell it apart from the real thing. That
limit is on lint output and on nothing else: whatever else you need to tell
the developer, this document included, is yours to say.

One of those four is not like the other three. A host that will not resolve,
a request that times out and a 5xx are the network's, and nothing in this
session fixes any of them. If your OWN client refused to run a command, the
network is not the problem at all, and what happens next is the developer's to
decide rather than yours. Stop at that step. Say what was refused and the
reason your client gave, say plainly that it was your client and NOT that the
server was down, and leave the decision with them. Quote the command and the
reason as they came, and leave it there: what a client allows is settled in
that client by the person whose machine it is, and this document has no
business naming a setting on it. Neither have you. Do not work around the
refusal, do not reach for a different tool, and do not ask the developer to
run the command by hand.
STEP 7 is the one exception, for its own lines and for the last of those
three clauses only, and it says why there.

A run that stopped that way can be picked up from the step it stopped at
rather than started over, once the developer has settled it their own way.
The one thing that does not wait is the STEP 3 credential, which lasts
15 minutes, so if longer than that has passed, fetch this document again
for a fresh one and run STEP 4 with that.

On Codex the sandbox denies the network by default, so each command here
that reaches it asks for approval: the lint in STEP 4, the upload in STEP 5,
and a second fetch of this document if one is needed. Expect them, and
answer each on its own; a denied one is the refusal case above.

Last, do not read an answer from the server as one of the failures above. A
429 on the mint, and a declaration sent back with the allowed values, are the
server replying and saying what to fix; --fail-with-body prints both bodies.
Read them and follow the step they belong to rather than stopping.

STEP 1. A SHORTER ROAD. Put one question to the developer before you start.

  Nothing in this step runs. It is a sentence you say and an answer you wait
  for, and it stands first because it decides whether the rest of this
  document is needed at all.

  Everything below is the long way round, done with curl because this session
  has no LexLint tools. If this client can add an MCP server, it need not be.
  The server is

    https://mcp.lexlint.io/mcp

  Adding it replaces this whole document: the lint becomes one tool call, and
  claim_trial_key takes the same no-account 30-day key this document takes,
  from inside the session and with no shell command at all. Nothing is left to
  do here first.

  Tell them that much, in one line: what it replaces, that the server stays
  in this client for every later session until they remove it, and that it
  costs one restart, which ends this session. Then wait. It is their machine
  and their client, so the answer is theirs to give, and the lines that would
  change either one are not in this step: STEP 7 at the end holds them, for
  every client.

  On their yes, go to STEP 7, do what it says, and stop there: the next
  session starts with the tools.

  On their no, or in a client that cannot add a server, go on to STEP 2 and do
  the same work with curl, and this document is one fetch away if it is wanted
  again. Either answer is a good one; what is not is starting STEP 2 without
  having asked.

STEP 2. Read the repository and work out two things.

  activities     What the app does, from this closed list. Pick every value
                 whose definition is true of the app, and where a definition
                 leaves you unsure, declare it: a behaviour you leave out is
                 unlinted, not passed.

  crawls_web
    fetches pages or files from sites you do not operate, by any automated
    means, whether or not the code calls itself a crawler.

  trains_models
    trains, fine-tunes or builds a model on data it collects. Calling somebody
    else's model is not this.

  generates_content
    makes text, images, audio or video with an AI model for anyone but the
    developer to see. Somebody else's model counts, and so does a hand-run
    script whose output is published.

  deploys_chatbot
    offers a conversational AI interface that people talk to, in the product
    or acting for it, whether the model is yours or a vendor's.

  automated_outreach
    sends people messages by email, text, call or direct message that the
    software initiates, rather than a person sending each one.

  high_risk_decisions
    makes or scores decisions about a person with legal or similar effect:
    hiring, credit, housing, insurance, education, health, benefits or access
    to essential services.

  processes_voice
    records, stores, transcribes or analyses human voices, including call
    recordings and voice messages, with or without a model anywhere in the
    product.

  processes_biometrics
    handles body or behaviour measurements that identify a person: face
    geometry, fingerprint, voiceprint, iris. A photo is not this; recognising
    someone from one is, as is your notice saying you may.

  publishes_adult_content
    makes sexually explicit material available, whether it is yours or your
    users'.

  operates_social_platform
    runs a service where users post content that other users see, or find and
    connect with each other.

  serves_minors
    is used by people under 18 or is likely to be: it is aimed at them, or it
    is open to everyone and does not keep them out. Data about minors
    collected elsewhere is the data activity, not this one.

  operates_app_store
    distributes other developers' apps: a store, a marketplace, or an
    operating system that carries one.

  ships_mobile_app
    distributes an app through somebody else's store, Apple's, Google's or
    another; running the store is operates_app_store.

  aggregates_content
    republishes, excerpts or indexes news or other publishers' content, by any
    means.

  distributes_software_product
    makes software available to others in any form: a desktop app, library,
    package, CLI, firmware, or a server others self-host. A service used only
    through a browser or API is not this.

  handles_health_records
    is a HIPAA covered entity or business associate, or a health-sector entity
    under a national regime. Storing health data does not make an app one;
    being the regulated party does.

  provides_financial_services
    is a bank, insurer, payment, credit or investment firm, or a designated
    critical ICT provider to one. Moving money does not make an app one;
    holding the licence does.

  operates_essential_service
    is an essential or important entity under NIS2 or a transposition, or a
    designated critical-infrastructure operator (energy, transport, banking,
    health, water, digital infrastructure).

  is_listed_company
    is a public company, or files periodic reports with a securities regulator
    such as the SEC, whatever the software does.

  provides_telecom_services
    provides a public telecommunications network or an electronic
    communications service, including Internet access.

  jurisdictions  Where it operates, as lowercase "/"-separated slugs: "us",
                 "us/ca", "eu", "gb", "kr". A slug is the jurisdiction's
                 UnGovr Atlas path: California is https://ungovr.org/us/ca and
                 its Atlas ID is urn:ungovr:us/ca. A deeper or unresearched
                 path resolves to the nearest jurisdiction with law, and the
                 jurisdictions whose law is researched are listed at
                 https://lexlint.io/law for the developer to check. The server
                 resolves whatever you send and names what it resolved to in
                 its reply, so there is nothing to look up anywhere else and a
                 slug taken from a web search is the one that quietly lints
                 the wrong place. Name every one you can support from the
                 repository. If all you can establish is the operator's own
                 country, declare that and say so when you report.

  Read the dependency manifests, the README, any privacy policy, any robots or
  crawl handling, and any deployment or region config. Answer this from the
  repository rather than asking the developer to fill it in.

  What comes back is decided by a fixed, rule-based match of these two lists
  against the corpus, never by a model reasoning about the law: the same
  lists, the same corpus build and the same instant always give the same
  findings, so the lint is exactly as right as the declaration.

STEP 3. Here is your trial credential:

    ung_claim_eyJ2IjoxLCJ0IjoxNzkwMTI5NDU1LCJuIjoiYjNkNjUwYzg0YTRjNTZlNiIsImsiOiIyMTYuNzMuMjE2LjExNyJ9.aZL_tTpSKKExtkhITWW5PqaEUQN_2098sdCUbMlw8zA

  It is nobody's secret and it opens nothing of the developer's. It belongs
  to no account, this server minted it for this fetch, it lasts 15
  minutes, it can be used once, and the only thing it does is let STEP 4 run.
  No account, no sign-in, no email, and nothing to request.

  It appears in this document once, above. Every fetch of this document
  carries a fresh one, so a copy you fetched earlier holds a different
  credential: use the one in the copy you are following. Presenting it on the
  STEP 4 call mints a 30-day UnGovr Open Data key good for 50 requests and
  runs the FULL lint in the same call. It is handed to you here, rather than
  minted by a command of yours, so that the only network call you make before
  the upload is the lint itself: one request, to one host, carrying the two
  lists from STEP 2.

  It was issued to the address this document was fetched from, and that
  address is the only thing it is bound to. Presenting it from a different one
  is reported back in the reply and still mints the key today, because that
  check is being measured before it is turned on.

  A credential that arrives in your context is recorded in the session
  transcript, and so is the key that comes back. Say so to the developer
  before STEP 4.

STEP 4. Run the lint.

  Three things before the command. Put the step 3 credential in KEY, from the
  value printed above; nothing here prints it again. Substitute your own
  STEP 2 lists for the two arrays in the -d argument, which are examples and
  are not your declaration. And show the two lists to the developer before
  you send them, with every value a definition left you unsure of marked as
  such, and wait for their answer: what goes is what they would have sent,
  and a value they strike or add changes the whole lint. In a headless or CI
  session nobody can answer: send the lists as you read them, and name the
  values you were unsure of in the report.

  Run it from the developer's own machine, never through a proxy or another
  host. That is about the address the credential was issued to, and not about
  anybody's network policy: a sandbox, a company proxy or an egress rule the
  developer's own machine already sits behind is fine, and it is routing the
  call through some third host to get around one that will not work.

    mkdir -p -m 700 /tmp/lexlint-first-run
    chmod 700 /tmp/lexlint-first-run
    curl https://mcp.lexlint.io/rpc -sS --fail-with-body \
      -o /tmp/lexlint-first-run/lint.json \
      -H 'Content-Type: application/json' \
      -H "X-API-Key: $KEY" \
      -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"run_lint",
           "arguments":{"activities":["crawls_web"],"jurisdictions":["us","eu"]}}}'

  A full run is over 100 KB, and -o writes it to
  /tmp/lexlint-first-run/lint.json: outside the repository, so nothing in it
  can be committed, and in a directory only this account can open, because on
  the credential path the file holds your 30-day key. If the chmod refuses,
  the directory is not yours: stop, and say so. If your client gives you a
  scratch directory of its own that other accounts cannot read, a directory
  you create inside it is as good a place, and that directory takes
  /tmp/lexlint-first-run's place in every command here, STEP 6's rm included:
  the rm names the directory this run made, and nothing above it. Read what
  you need out of that file. On this path the reply is indented, one value
  per line, and the lint is result.structuredContent, so your client's own
  file reader can page through it a few hundred lines at a time, and a single
  grep -o on the file works too.

  Nothing here is kept from the developer: the file is on their disk and they
  can open it whenever they like. Printing pieces of the reply is the hazard,
  not reading it: on the credential path it holds your key, and a printed key
  lands in the transcript, in the scrollback and in any log the session
  writes. It sits at result._meta.lexlint_trial.api_key, and on a failed reply
  at error.data.lexlint_trial.api_key, so a one-liner that prints the whole
  file prints the key along with it, and a grep for api_key prints nothing
  else at all. Never grep the reply for api_key, and never echo the key: take
  it into a shell variable, the way STEP 5 does, and use it from there. If
  your client refuses a command here, the clause at the top of this document
  is the answer.

  A refused call lands in the same file with HTTP 200, so curl's exit code
  says nothing about it. Check first: grep -c '^ "error"' on the file answers
  0 for a lint and 1 for a refusal, and a refusal's error.message says what to
  fix and which step it belongs to. Never read findings out of a reply that
  carries "error".

  Run STEP 4 once per declaration. If reading the reply makes you doubt a
  value you declared, say so beside the report in STEP 6; do not re-declare
  and run it again unasked. Each run spends one of the key's 50 requests, and
  a second declaration is a second run nobody asked for. Sending the SAME
  declaration again after a call that failed, which the paragraphs below tell
  you when to do, is not a second run in that sense.

  Your 30-day key is in the reply at result._meta.lexlint_trial.api_key:
  persist it as UNGOVR_API_KEY and use it as X-API-Key on every later call.

  Look for that key on a FAILED reply too, at error.data.lexlint_trial.api_key.
  Redeeming spends the credential once, so if the mint succeeded and the lint
  then failed for its own reasons, the key exists and this reply is the only
  place you will ever see it. Persist it before you do anything about the
  error, then retry with it.

  If the reply is an error with code -32004, read error.data.reason: the
  credential was spent, expired, or (when enforcement is on) issued to a
  different address. Fetch this document again first: every fetch carries a
  fresh credential, and the new copy's STEP 4 runs with it. If that is refused
  too, open

    https://lexlint.io/trial

  in a browser, press the button, and paste the key it shows into this
  session; that paste is recorded in the transcript like any other, so say so
  first, and a developer who would rather it were not can put the key in
  UNGOVR_API_KEY themselves and tell you it is there.

  If the reason is cap_reached, this address has taken its trial keys for
  today; sign in at https://ungovr.org/cli-login?client=lexlint instead.

  There is no second way. This deployment runs the lint with a key or not at
  all, so a step 3 you could not finish is a step 4 you cannot reach. That is
  a stopping point rather than something to get past: report it and stop. Do
  not POST a declaration to /first-run hoping for a lesser run: it answers 503
  here, and a 503 is the unreachable case at the top of this document rather
  than a result with less in it.

  If the reply refuses the declaration, it says what is wrong and what the
  allowed values are: fix it and send it again.

STEP 5. Upload the run, with the developer's yes and not without it.

  This is the closing step of every keyed run whose findings array came back
  with something in it. It stores that run against the key's account and
  answers with a link to it.

  What the call sends is the two lists from STEP 2, the repository's name, and
  two values the STEP 4 reply carried: corpus_built_at and run_at. It does NOT
  send the findings. The server rebuilds those from the same declaration it
  answered minutes ago, judged at that same run_at, and refuses if its corpus
  has moved or the run is over an hour old, so what is stored is what the
  developer was shown. Nothing leaves here that is larger than the declaration
  you have already said out loud.

  It still has to be asked, because a stored run outlives the session. Ask in
  one line, show the two lists and the name, and wait. If your client prompts
  for the command below of its own accord, that prompt is the asking and their
  approval is the yes. If your client runs commands without asking, the
  question is yours to put, and you wait before running it.

  Skip STEP 5 entirely in a headless or CI session, when the findings array
  came back empty, or when step 4 ran without a key: the keyless preview
  carries no findings, and you hold no key to send one with.

  Set KEY to the 30-day key, which REPLACES whatever step 4 put there: on the
  credential path that was the single-use claim token, and it is spent. The
  30-day key is the one you took in step 3, or, if you presented the step 3
  credential on the step 4 call, the one that reply carried:

    KEY=$(jq -r .result._meta.lexlint_trial.api_key /tmp/lexlint-first-run/lint.json)

  Then send the upload. Substitute the repository's name, your own STEP 2
  lists, and the corpus_built_at and run_at the STEP 4 reply carried:

    curl https://mcp.lexlint.io/rpc -sS --fail-with-body \
      -H 'Content-Type: application/json' -H "X-API-Key: $KEY" \
      -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"upload_lint_run",
           "arguments":{"app_name":"...","activities":["crawls_web"],
           "jurisdictions":["us","eu"],"corpus_built_at":"...","run_at":"..."}}}'

  If your client refuses it, do not ask the developer to run it by hand and do
  not look for another way to send it. Tell them it was refused and what the
  refusal said. Nothing is stranded by that: the upload carries the
  declaration and not the findings, so there is no file waiting for a later
  session to send. Once STEP 7 is done, the next session in this repository
  lints and uploads in one tool call, and the run that lands is a fresh one
  against the corpus of that day.

  The reply carries run_url and, for a trial key, share_url: a link that
  opens the full run with no sign-in for 30 days. To keep the run past
  that, the developer signs in (an account is free) at

    https://ungovr.org/cli-login?client=lexlint

  and pastes the trial key at

    https://my.lexlint.io/claim

  The run, its project and the key move to the account. To have the run
  deleted instead, write to hello@ungovr.org quoting the link. The
  directory, which holds the reply and, on the credential path, your key, is
  removed at the end of STEP 6.

STEP 6. Report what came back.

  If nothing came back, there is no findings report. Say so, and stop. What
  you do owe the developer in that case is the failure the guard at the top of
  this document asks for: which command failed, what it printed, and the two
  lists you were about to declare.

  From the KEYED run: one table of findings, worst first, each with its
  citation. Severity is the lint's own, never yours. Do not soften a warning
  and do not invent a fix the payload does not carry. Then say which findings
  rest on exactly one declared activity: the reply groups them for you at
  result.structuredContent.declaration_sensitivity, keyed by activity with
  the finding ids, so the developer can see what a value they doubt is
  carrying. The full reporting rules are at
  https://github.com/ungovr/lexlint/blob/main/AGENTS.md

  From the upload, one of these four, and say which: the share_url (or
  run_url) the reply carried, so the developer can read the full run again;
  that the developer said no; that it was asked and did not land, refused,
  failed or state unknown, with what came back; or that STEP 5 did not apply,
  headless, no findings or no key, with the reason. A keyed run with findings
  that reports none of the four has skipped the ask: go back and ask. STEP
  7's tools store the next run in one call.

  Write nothing into the repository: the report is for the session, the
  stored run is what the developer keeps, and a file of yours in their tree
  is one the next git add commits.

  Then clear the directory, whether or not step 5 ran and whether or not it
  was refused: on the credential path the reply file holds your key, and
  nothing in there is needed by a later session.

    rm -rf /tmp/lexlint-first-run

STEP 7. Hand every later run to the plugin.

  Two ways in, and the lines below are the same either way: STEP 1 got a yes
  and sent you straight here, or it got a no and you have come the long road.
  From the long road, ask once more, because the answer is a different one
  now. The 30-day key you hold, from step 3 or from the step 4 reply, is what
  makes the tools worth installing, and the run they just read is what says
  whether they want another. With the key in the environment a run is one tool
  call, the reply arrives as lines, and nothing here is needed again.

  STEP 7 is the developer's to do, because it changes their shell profile
  and their client: show them the lines for their client, say what each one
  changes, and on their yes, do them.

  It is also the one step where the developer running the lines themselves
  is the step and not a way around anything. A client that asks before it
  runs a command will ask; a client that decides on the agent's behalf may
  decline a line that installs a plugin or registers a server, and that is
  the client doing its job. If yours declines, say so, show the lines once
  more, and leave them with the developer: they change that person's own
  client and profile, they carry nothing of the developer's outward, no data
  and no key, and the next session they start after running them is the one
  with the tools. That is the whole of what this step lifts, and only for
  these lines. The rest of the rule at the top stands here as everywhere:
  do not write the server into a config file by another route when the
  command for it was declined, do not reach for a different tool to do what
  the line would have done, and a refusal at any other step is never a
  reason to come here and install the tools instead. Name no setting, rule
  or flag that would let you run them yourself: what the client allows is
  the developer's to change, unprompted, and offering it as an option is
  the coaching this document exists not to do. Every other command in this
  document keeps the rule at the top.

  First the key, if you hold one. It goes in their shell profile as
  UNGOVR_API_KEY, and in bash and zsh that is

    export UNGOVR_API_KEY=the-30-day-key

  and the fish and PowerShell forms are in the plugin repository at
  https://github.com/ungovr/lexlint#get-a-key

  Hand them that line, and write the key nowhere else instead: a file
  nothing sources, a note, a private directory of your own, is a key nothing
  reads, so the next session starts with no key and the mint is spent.

  Straight from STEP 1 there is no key yet; STEP 1's own paragraph says where
  it comes from on this deployment, and that one governs, not this.

  On Claude Code, install the plugin

    claude plugin marketplace add ungovr/lexlint
    claude plugin install lexlint@lexlint

  and restart the session once: the plugin and the key are both read at
  process start, so with the key already in the profile one restart covers
  both. Say what that adds before the yes: every later session in this
  client will carry LexLint's server and can call its tools, until the
  developer removes it. The restart is the inconvenience and the server is
  the decision.

  On Codex, register the server

    codex mcp add lexlint --url https://mcp.lexlint.io/mcp

  which writes the transport and not the key, so add these two lines by hand
  to the [mcp_servers.lexlint] entry it just wrote in ~/.codex/config.toml

    http_headers = { "X-API-Key" = "" }
    env_http_headers = { "X-API-Key" = "UNGOVR_API_KEY" }

  The second value is the variable's NAME, and Codex reads the key from the
  environment it starts in, so restart the Codex session once after the
  profile change. The first line is what lets the server answer before there
  is a key: with the variable unset Codex sends no header at all, this server
  reads no header as a sign-in it cannot offer, and the tools never appear.
  An empty header is read as no key, the tools appear, and the variable's
  value replaces it the moment it is set. On every other client the server
  block to paste is at

    https://mcp.lexlint.io/#setup

  If STEP 5 was refused, the first thing to do in that new session is to lint
  and upload again. Nothing was left on disk to resend and nothing needs to
  be: the upload carries the declaration, not the findings, so a fresh run
  against the day's corpus is the same work and the tools are now there to
  do it without a shell.

  A trial key carries 50 requests in total across its 30 days. An account key
  has no such lifetime total; any limits on it are separate.

Nothing of the developer's source, schema, data, prompts or git history is
uploaded. What the portal keeps is the lint's own output, the two lists it
was run against and the repository's name, all shown before they go, and
nothing in the working tree is changed. The trial key was issued to the
developer and is theirs to keep or discard; kept as UNGOVR_API_KEY, it goes on
working for 30 days, and STEP 7 is where that is offered to them.

LexLint findings are research summaries of public legal sources, not legal
advice, not a certification, and not authorization to access any system. For
decisions that matter, consult qualified counsel in the relevant jurisdiction.