An open-source, local-first endurance coaching plugin for ChatGPT Work mode and Codex.

The model is never the permission system.

StrideOS is a package of coaching skills—not another training-account app. It helps an athlete build a complete athlete map, use training evidence from tools and accounts they choose, plan running and strength work, use optional fueling support, and create a Training Circle that can be shared with a real coach, experienced runner, or trusted friend.

The athlete stays in control. StrideOS may explain and propose; it does not silently activate a plan, log uncertain food, expand sharing, or perform an external write. The plugin is an editable package, not a central authority over the athlete's computer or accounts.

Built with Codex and GPT-5.6 for OpenAI Build Week 2026. Licensed under MIT.

• Open the live StrideOS landing site
• Open the live Training Circle demo
• Watch the StrideOS demo video

codex plugin marketplace add Kikser1214/strideos-harness --ref main
codex plugin list
codex plugin add strideos@strideos

Supported surfaces. According to OpenAI's plugin documentation, installed or workspace-shared plugins work in Work mode on ChatGPT web, in Work mode or Codex in the ChatGPT desktop app, and in Codex CLI—not in Chat mode, the IDE extension, or mobile. Work web cannot read a local folder, and workspace policy may control personal plugins.

To inspect or develop the cloned source locally, register the repository root as the marketplace instead:

git clone https://github.com/Kikser1214/strideos-harness.git
cd strideos-harness
codex plugin marketplace add .
codex plugin list
codex plugin add strideos@strideos

For ChatGPT desktop, restart the app, open Plugins Directory, install or enable StrideOS, and begin a new Work/Codex task. For Codex CLI, begin a new session after codex plugin add.

@strideos Start first-time onboarding.

StrideOS offers the local questionnaire in ChatGPT's in-app browser when it is available; otherwise it continues with the equivalent grouped chat interview.

StrideOS skills are explicit-invocation only. This keeps the public plugin's rules out of unrelated personal, work, or coaching tasks unless the athlete deliberately selects @strideos or one of its bundled skills.

An installation is a cached snapshot of the source at install time. Editing a fork or local clone does not rewrite an already loaded task: update the plugin version/cachebuster, reinstall that source, restart when required, and begin a new task. See Ownership, forks, and local extensions.

The distributable package lives at plugins/strideos. The repository also includes marketplace metadata for the ChatGPT desktop plugin directory, following OpenAI's repository-marketplace format. The package contains a real .codex-plugin/plugin.json, six skills, UI metadata, references, an icon, and its MIT license. It does not claim an MCP server, hosted backend, parser, native companion, or provider integration that it does not ship.

These are broad intent boundaries, not six single-purpose features. Strength, run-walk progression, race planning, method research, provider routes, meal images, training review, scheduled coaching rhythms, dashboard building, and human-coach feedback live inside the relevant core skill so the plugin can route requests without overlapping triggers or conflicting authority rules.

The Training Circle is built by the build-coach-room skill.

The skills are self-contained enough to use conversationally. This repository also includes a deterministic local reference implementation and two Sites templates so contributors and judges can inspect and test the rules behind the coaching behavior.

The Training Circle is the central collaboration feature. The athlete decides:

• who is invited;
• which workouts, dates, and fields they can see;
• whether nutrition is included;
• how long access lasts;
• when access is revoked.

A reviewer can comment on an exact workout or week and suggest a structured edit. They cannot activate a plan, invite other people, widen sharing, or operate a provider account. An accepted suggestion becomes a new athlete-visible proposal with a before/after diff; the existing plan stays unchanged until the athlete approves it.

The included athlete-coach-demo shows the complete product flow with a clearly synthetic 3:20 marathon runner: detailed history, current week, full plan, annotations, coach comments, revision proposals, and athlete-only approval. Its current identity and persistence are demo-only, so the repository does not describe it as production-private.

StrideOS asks for information only when it can change safety, the recommendation, delivery, or communication:

• current activity, running history, recent load, and useful benchmarks;
• pain, relevant symptoms, injury, conditions, medications, and clearance;
• goal, event date if any, expectations, and motivation;
• realistic schedule, work pattern, sleep, stress, terrain, climate, and barriers;
• strength experience, technique confidence, equipment, preferences, and limitations;
• athlete-selected phone, watch, provider, file, or manual evidence;
• coaching style, optional nutrition, collaboration, automation, and delivery preferences.

Conversational onboarding keeps that detailed map but collects it in eight coherent rounds rather than a long chain of isolated questions. The athlete can answer a related group in ordinary prose, skip optional details, review what StrideOS extracted, and receive follow-ups only for required information, safety ambiguity, or a decision that changes the next step. Conditional nutrition and device-delivery details appear only when enabled.

When the repository is running locally, the preferred onboarding surface is the browser questionnaire at http://localhost:4173. StrideOS asks the athlete to choose Open the browser questionnaire (recommended) or Continue here in chat. After the athlete chooses the questionnaire, ChatGPT opens it in the in-app browser and keeps that embedded tab available throughout onboarding; StrideOS never launches a separate browser automatically. The athlete selects everything in the wizard, then the agent reads the completed normalized athlete map from GET /api/bootstrap; it does not scrape the page or repeat the questionnaire in chat. The eight-round conversational flow is the equivalent fallback for Work/cloud or any host that cannot reach the local runtime or embedded browser.

Data is requested early enough to prevent duplicate work. For every selected provider, the athlete chooses the exact scopes—activities, workout details, route/elevation, recovery, sleep, and optional weight trend—plus a history window and whether to read now before planning or later. StrideOS reflects that scope for explicit confirmation. When read-now evidence is authorized, it retrieves and normalizes the evidence before asking the athlete to manually reproduce provider-observable history; the athlete then confirms the extracted baseline and adds the human context the device cannot know. No read grants a workout or calendar write.

Someone who does not know training terminology is not asked to choose among unexplained systems. For a suitable beginner who wants StrideOS to decide, the starting recommendation is three separated run-walk-run sessions, two short technique-first strength sessions, and optional easy cycling when it fits schedule and recovery. Running grows gradually and walking reduces only when pain, recovery, and recent effort support it.

A request for Norwegian-style threshold work, a run-walk protocol, a regional training tradition, or another named method starts research—it does not bypass the athlete assessment.

StrideOS verifies the exact method with current primary or authoritative sources, identifies the intended population and recovery demand, compares it with the athlete's history and goal, and recommends full use, a conservative adaptation, or rejection. It never treats “Norwegian training” as automatically meaning double threshold or describes “African training” as one universal system.

Strength belongs in every eligible plan. Missed sessions never create catch-up stacking. New pain or safety evidence overrides an approved progression.

StrideOS does not say a provider is “connected” because a page is open, a client exists, or an athlete approved an idea. Reads and writes are resolved independently.

StrideOS provides official recommendations; it does not define an allowlist. For a new setup, use this precedence:

1. provider-documented official self-service MCP, API, or user-owned native companion;
2. user-selected attended browser or computer use in the athlete's own visible authenticated session;
3. provider-issued export and supported local file import;
4. manual entry.

The public package ships no unofficial provider client, private-endpoint recipe, or provider-specific browser executor. Browser and computer-use tools belong to the host, not to StrideOS. The athlete opens the provider page and performs login and MFA; StrideOS never requests, types, reads, copies, or stores credentials, cookies, session tokens, recovery codes, or browser storage. Browser work is visible, attended, interruptible, and never scheduled or headless.

The upstream route catalog controls what StrideOS recommends, not what an owner may use. Before recommending a new setup, the data skill re-checks current first-party provider sources and detects whether the current ChatGPT, Work, Codex, or other AI surface actually exposes attended browser/computer use. If an athlete explicitly chooses an existing local script, another plugin, or another external host capability, StrideOS's provider-route guidance steps aside. The agent handles that capability as if StrideOS were absent, subject to host permissions and ordinary exact approval for writes. Upstream does not bundle, describe, certify, or support that external capability.

These are the public routes the skill can explain or help the athlete configure, not bundled integrations. This release includes no provider client, MCP server, native companion, provider-specific browser executor, or file parser inside the plugin package. The optional reference runtime separately parses its tested FIT, GPX, TCX, and CSV inputs.

Attended browser/computer use is a host capability the athlete may choose for any provider; see 'Works alongside the accounts the athlete already has' above.

The source-backed upstream recommendation catalog is rules/connector-playbooks.json. It records capability, model-context considerations, route status, first-party sources, limitations, and review date. It is not an enforcement boundary for a fork or an explicitly supplied local adapter.

A real host tool, official connector, companion, or explicitly supplied local adapter must exist before approval is offered. A provider write preview is bound to the provider, route, account, capability, operation, context, exact payload, athlete state, and expiry. One approval authorizes one write.

Expired, altered, mismatched, replayed, scheduled, headless, or unattended attempts stop. After a tool reports success, StrideOS still requires visible verification of exactly one write before it calls the action performed. The checked-in Garmin-shaped reference action remains explicitly simulation only; host browser/computer use and user-supplied adapters are separate capabilities outside that simulator.

The fueling skill supports off, loose, guided, detailed, and number_free modes. Number-free preference, under-18 status, a relevant tracking concern, do_not_use weight context, and clinician-prescribed constraints override detailed tracking.

Meal and fridge photos are estimates. A photo cannot prove ingredients, portions, allergens, cooking fats, cross-contact safety, or nutritional values. The athlete corrects and confirms the normalized record before logging, and the bundled state never retains the raw image.

StrideOS keeps model reasoning separate from authority:

1. Sense — use only athlete-authorized evidence and preserve source and freshness.
2. Reason — combine deterministic analysis with optional GPT-5.6 explanation or image reasoning.
3. Gate — check the intended action against current athlete state, the selected tool's real capability, host permissions, and the installed package's configured rules.
4. Propose — show the exact recommendation or state change and explain why.
5. Approve or stop — activate only the exact approved local change; external writes additionally need a real selected tool and one exact approval.
6. Verify — call an action performed only after its resulting state is read back or visibly attested.

These are research directions, not features in the current release, and they carry no promised delivery date. The goal is to extend the current approval-gated coaching loop across longer time horizons while keeping retention visible, optional, and athlete controlled.

• Longitudinal athlete memory — connect completed sessions, morning and evening check-ins, symptoms, recovery, fueling, environment, and athlete notes across weeks, months, and seasons. Recurring patterns—such as a side stitch appearing under particular combinations of load, heat, timing, or fueling—should be surfaced as testable hypotheses, never diagnoses or claims of causation.
• Training response analysis — compare what was planned with what was completed, what felt sustainable, and what repeatedly produced useful adaptation over one-to-three-week, two-to-three-month, and annual windows. Preserve missing-data and confidence limits instead of manufacturing certainty.
• Running form over time — compare athlete-supplied running videos or images, label observations with uncertainty, suggest practical form or strength work when useful, and track whether later evidence supports the intervention. This remains movement feedback, not medical assessment.
• Flexible fueling history — let each athlete choose anything from simple meal photos to confirmed macro tracking, then examine longer-term relationships with training and recovery at the level of detail they want.

The roadmap does not change the current authority model: an insight is evidence for a conversation, not permission to alter a plan, retain new data, expand sharing, or perform an external write.

The plugin does not require the web reference implementation. Use it when you want to inspect the deterministic state machine, onboarding, dashboard, imports, nutrition confirmation, decisions, and tests.

npm run setup

On Windows:

npm.cmd run setup

Open http://localhost:4173. The first page is real onboarding; synthetic demo data is never silently loaded as a personal athlete.

Useful commands:

npm run doctor
npm run verify
npm run test:plugin
npm run reset
npm run brief -- --kind morning_brief

• doctor checks Node, dependencies, environment syntax, state permissions, privacy artifacts, and clean-install requirements without printing secret values.
• verify runs diagnostics, syntax checks, and the complete acceptance suite.
• test:plugin checks the plugin manifest, six skills, official-recommendation language, installed ownership, and unofficial-recipe regression guards.
• reset clears the configured local athlete state and returns to a true first run.
• brief produces a read-only payload for an optional scheduled prompt; it never changes a plan or provider account.

The deterministic experience needs no wearable, provider account, database, deployment, or OpenAI key. Optional GPT-5.6 mode uses a server-side OPENAI_API_KEY only after the athlete enables cloud processing; deterministic safety and permission rules remain authoritative.

plugins/strideos/                     Installable StrideOS plugin package
  .codex-plugin/plugin.json          Plugin manifest and UI metadata
  skills/coach-athlete/              Onboarding and coaching orchestration
  skills/plan-training/              Training plans and method research
  skills/use-training-data/          Provider routes, imports, and provenance
  skills/support-fueling/            Optional fueling and photo boundaries
  skills/schedule-coaching/          Preview-first scheduled coaching rhythms
  skills/build-coach-room/           Training Circle collaboration
rules/onboarding-schema.json         First-run question inventory
rules/connector-playbooks.json       Source-backed official recommendation catalog
rules/harness-policy.json            Deterministic action boundaries
src/                                 Local reference engine and HTTP API
public/                              Local reference interface and PWA assets
sites/athlete-coach-demo/            Synthetic Training Circle product template
sites/strideos-landing/              Public project website
docs/                                Architecture, install, research, demo, and release guides
test/                                Unit, HTTP, provider-policy, and plugin-package tests

The repository retains its original GitHub URL, strideos-harness, but the shipped product is the StrideOS plugin package. src/harness.mjs is the internal deterministic decision gate, not the product identity.

The release gate includes:

• current strict portable validation of the final plugin, six skills, route-safety language, and repository marketplace metadata;
• official Codex validation of the same manifest and skill metadata during packaging, including the installed plugin copy;
• the Codex marketplace listing showing the strideos@strideos plugin and package validation proving its six-skill inventory;
• an isolated successful Codex install using a relative local path;
• root diagnostics, syntax checks, and the complete Node acceptance suite;
• landing-site build and rendered-page test;
• athlete-and-coach site build and rendered-page tests;
• a production dependency audit refreshed on July 20, 2026 with zero findings;
• git diff --check.

Coverage includes beginner onboarding, safety stops, strength recommendations, training-plan approval and replay protection, workout annotations, nutrition confirmation, imports and freshness, provider route recommendations, attended-session boundaries, user-supplied adapter handling, one-use expiring write envelopes, private-companion access control, and plugin packaging.

• StrideOS provides general wellness coaching, not diagnosis or treatment.
• No unofficial provider client, private-endpoint recipe, or provider-specific browser executor ships in this release. Attended host browser/computer use and explicitly supplied local adapters remain available when the user chooses them and the host permits them.
• The Training Circle Site is a product template until real identity, private persistence, invitations, and revocation are bound to a production surface.
• Scheduled tasks may summarize and ask questions; they cannot browse a provider, activate a plan, log food, or perform an external write.
• The repository contains synthetic athlete data only.

Read PRIVACY.md before hosting a personal instance.

• Clean-clone and plugin installation
• Ownership, forks, and local extensions
• Cloud Work new-user and presentation test
• Architecture
• Build plan
• Provider access routes
• Data access and provenance
• Onboarding research
• Training-plan engine
• Nutrition companion
• Dashboard contract
• Automations
• ChatGPT Work and Sites
• Judge guide
• Demo video script
• Release checklist

StrideOS is licensed under the MIT License. Garmin's FIT SDK keeps its own license and is not relicensed by this project; see Third-party notices.

Contributions are welcome for coaching skills, training-method research, deterministic safety, provider guidance, data normalization, privacy, testing, and human-coach collaboration. The upstream project documents official routes and never publishes unofficial access recipes; its recommendations are not an allowlist. The MIT-licensed source may be forked and changed, and user-selected scripts, plugins, browser tools, computer use, and local adapters remain outside upstream enforcement.