Oynix

Get started

See how it works

From an empty repo to an answered question, in one flow. Install Oynix, index the code on your machine, connect the memory buried in your tickets and docs, then watch your coding agent answer a question that touches code, a past decision, and a second repo at once.

Set up in a few commands

Real commands, in the order you run them. Same flow you will watch below.

Free, and everything runs on your machine.

  1. 1
    curl -fsSL https://oynix.dev/install-local.sh | sh

    One binary, plus the MCP server your agent talks to. No Docker, no database to run.

  2. 2
    oynix init

    Sets up this machine and wires your coding agent. Your keys stay in your own config.

  3. 3
    oynix connector add --path .

    Indexes the repo you are standing in. Parsed into a graph on this machine, at AST precision, with no LLM cost. Add as many folders as you like.

  4. 4
    oynix connect

    Opens the Connectors page. Add GitHub, Jira, Confluence and Google Drive so the decisions behind the code become nodes linked to it.

  5. 5
    oynix graph

    See what it built. Functions, files, and the calls between them, next to the tickets and documents that explain why.

There is no ask command to run. Your coding agent asks the graph for you, in Claude Code, Cursor or any MCP client, from the moment init finishes.

Folders on this machine need no token. For a private repo on GitHub, run oynix connect github once.

The payoff

Then ask

The graph is built and the org memory is connected. Now watch one question get an answer no single tool could give.

oynix — index the code, connect the org memory, ask

Code + org memory

“What should I know about the backup upload endpoint, including risks from past tickets?”

Oynix answers from the code and surfaces a past Jira ticket warning about a race condition on that exact handler. grep can search the files. It cannot reach the decision.

Cross-repo blast radius

“If I change the backups/upload endpoint, what breaks in the js-sdk client?”

Oynix traces the change out of the backend and into a second repo, naming the client code that breaks. A graph of one repo structurally cannot see this.

Inside your coding agent

Give your agent the same memory

Connect Oynix over MCP with one command. Your agent gets the code, the past decisions, and the cross-repo blast radius. It asks Oynix for the facts, then reasons on its own. Retrieval runs on your keys and costs zero Oynix tokens. Oynix is the memory, not the model.

Connect onceoynix mcp setup --client claude/codex

Writes the config and a routing hint so the agent reaches for Oynix, not grep. No secrets in the file. Swap --client codex for Codex, or any other agent.

Same memory, two different agents. Neither repo is checked out locally. Oynix connects the client to the server and names who owns each side.

Where your team already works

Or just ask in Slack

Add the Oynix connector to a channel and @mention it. The same org-aware answer lands in the thread, with the code it touches and the past tickets it came from.

Give your agents the memory they are missing.

One command. Your code is indexed on this machine and never leaves it.

Install OynixBack to Home