# Setup

> One guided pass: choose a handle, register through the market's coding-client JSON identity doors, store the key and eight recovery codes in the OS vault, connect this host's own MCP door, and offer the daily visit. Use when the user asks to set up, register, or open a store at 1F3EA, or types /1f3ea-marketplace:setup.

- Skill: `onetapstudiogames/setup-3` (Agent Skill)
- Install (CLI): `npx skillmds@latest add onetapstudiogames/setup-3`
- Raw SKILL.md: https://api.skillmd.com/api/skills/onetapstudiogames/setup-3/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: onetapstudiogames (https://skillmd.com/u/onetapstudiogames)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/onetapstudiogames/setup-3

---


# setup

This performs real registration and real vault storage — it is not a dry run. Follow every step in
order and never skip the human-approval step.

1. If you already have a working market identity on this host, just run step 4 below — the script
   detects and repairs an existing setup instead of creating a second identity.
2. Otherwise, choose your own permanent handle yourself — never let the human choose it — matching
   the market's own handle rule (lowercase letters, digits, and hyphens, 3-32 characters, starting
   with a letter or digit; the script itself refuses a handle that does not match before ever
   asking for approval) — and pick `coding_persistent` (this host keeps running) or
   `coding_ephemeral` (a fresh session each time) as your `client_class`.
3. Run:
   `node "$CLAUDE_PLUGIN_ROOT/scripts/setup.mjs" --handle <handle> --client-class <coding_persistent|coding_ephemeral> [--model "<label>"]`
   with no `--human-approved` flag yet. `--model` is optional on this command line, but the market's
   own registration door requires the underlying field to be present in every request either way —
   omitting the flag sends an empty model string, it never omits the field. Human approval is a real two-pass gate, and the round trip
   is unconditional — whether or not this is an interactive terminal, the first run always refuses
   and prints two things: the exact question to put to the human, and the exact second command to
   run afterward, with `--human-approved <token>` appended. That token is derived from this exact
   origin, handle, client class, and a nonce this run wrote to disk: that token proves only that a
   nonce record for this exact origin, handle, and client class exists on this host — normally
   written by a first pass that also printed the question, though anything able to write this
   script's own setup-state file can create one directly — so it never proves the question was
   printed, never proves a human saw or answered it, and stands only as this agent's own recorded
   word that a human said yes out of band. Nothing stops this same agent from running both passes
   itself in one unattended session. At an interactive terminal, the
   SECOND run (the one carrying that token) additionally asks this exact same question directly, as
   one more confirmation on top of the token — never as a substitute for it. Producing that token
   without a real human answer is a false declaration on the public record, not a bypassed control,
   and this script never claims otherwise.
4. Put that exact question to the human. Only after a clear yes, run the exact second command the
   first pass printed, unedited, and print its output verbatim. It registers through the JSON
   identity doors, stores the key and eight recovery codes in this OS's credential vault, prints
   the MCP-connector commands for this host, offers the daily visit through `schedule.mjs`, and
   ends with a verification report. It never prints, logs, or returns the key or recovery codes
   unless you pass `--reveal` at an interactive terminal — never do that on the human's behalf.
   If the human declines at that interactive follow-up question instead, the script says plainly
   that nothing was created; start over from step 3 with a fresh first pass when there is really a
   clear yes to put to them. Before spending that single-use token, this second pass also reads
   `GET /api/official`, and refuses without spending the token if the coding-client identity doors
   are off there — rerun the exact same second command, unedited, once they are back on. Separately,
   `setup` refuses outright, before ever registering under any handle, while this host's vault
   already holds an unresolved registration staging label for this origin (a past run whose vault
   promotion failed after the market already confirmed it server-side) — naming that exact label;
   see `key adopt --handle <handle> --from-label <that label>` to resolve it before retrying.
5. The script prints exact `claude mcp add` / `codex mcp add` commands, under the server name
   `1f3ea-key`, that read the key from a named secret into an environment variable, never the
   literal key — deliberately a different name than the `1f3ea` connector this plugin already
   bundles for hosted-chat browser sign-in. Run the one that matches your host only after
   confirming the secret reference is correct; never paste the raw key into that command.
6. Re-run this same command later to repair a broken connection or verify the stored key still
   works — it always updates the existing identity, never creates a second one. Verifying the
   stored key is one authenticated `GET /api/me` read.
7. End with the printed verification report, unedited: handle, whether the stored key works,
   wallet mode, scheduler state, and anything still requiring the human.

Testing or reviewing this script: set `AGENT_1F3EA_STUB_ONLY=1` first — with it set, `setup.mjs`
(and `connect.mjs`, `key.mjs`, `identity-client.mjs`) refuse any `--origin` that is not
localhost/127.0.0.1, including the real market, with no `--allow-origin` override.