Stored credentials

DataMind Oda keeps the credentials it uses for connected services: model providers, connected tools and web search. This page is the reference for the store behind them: where it lives on this computer, the order Oda reads values in, and what protects the file. The everyday steps for saving a provider key are on Set up models and providers.

Where saved credentials live

Oda keeps saved credentials in one file inside Oda's home folder and settings files, created so that only your user account can read it. Two kinds of credential arrive there:

• A key: a value saved for a name, such as a model provider's key from Settings > Models. Oda uses it for every request that names it.
• A sign-in: what Oda obtained when you signed in to a connected service, saved so later requests can use that service. Oda keeps it exactly as it was issued.

Oda never shows a stored value back, in a settings page or in a message; what it reports about the store is whether a value is set and where it comes from, never the value itself.

Which value Oda uses

Oda looks up a name in one order: the first place that has a value wins.

• The environment is read once, when Oda starts. A variable added afterwards is not seen until the next start.
• A name the environment supplies is read-only. Saving or removing that name is refused, and the message asks you to unset it in the environment DataMind Oda starts from instead.

Saving, changing and reloading

• A saved key takes effect from the next request. No restart is needed, and a saved value survives a restart.
• A change to the file is picked up automatically, including a key or sign-in you delete. If your edit and one of Oda's own writes land at the same time, both changes are kept.
• An unreadable file is never treated as empty. At startup, Oda refuses to load a file it cannot trust. While Oda is running, it keeps the last good content and warns; a save that would overwrite a file Oda cannot parse fails instead.
• An empty value is never stored. A credential is removed by removing it, not by blanking it.

How the file is protected

• Only your user account can read it. Oda creates the file with owner-only permissions. On macOS and Linux, Oda also refuses to load a file that any other user can read; the message tells you to run chmod 600 <file> before starting again. On Windows, this check does not apply.
• Discretion, not a boundary. The file relies on your computer's file permissions. Those keep other user accounts out. They do not keep out programs that run as you, and Oda's own work on this computer runs as you, so treat the store as a convenience, not as a boundary.

Questions, answered

Where does Oda keep saved credentials?

In a credential file inside Oda's home folder, created so that only your user account can read it. Keys you save through Oda's settings, for example a provider key on Settings > Models, and the sign-ins obtained for connected services all live in that one file. Oda's home folder and settings files covers the folder itself.

Which value does Oda use when the same key is set in more than one place?

The first place that has a value wins: the environment Oda starts in, then the stored file, then a .env file in the folder you launch Oda from, then a .env file in Oda's home folder. A key you save beats both .env files, so it is used even when an older value sits in one of them.

Why can't I replace a key that comes from the environment Oda starts in?

A value from the environment is this run's explicit choice, so Oda treats it as read-only and refuses to save or remove that name. Oda reads the environment once, when it starts, so the fix is to clear the variable where you start Oda and start Oda again. Until then, a saved key cannot take its place.

When does a saved key take effect?

From the next request that names it. Oda needs no restart, and a change made in the credential file is picked up the same way. Saved values survive a restart.

I edited the credential file myself. What happens?

Oda notices the change and uses it, including a key or sign-in you delete. If your edit and one of Oda's own writes land at the same time, both changes are kept. An empty value is never stored: a credential is removed by removing it, not by blanking it. If the edit cannot be read, Oda does not treat the file as empty: while Oda is running, it keeps the last good content and warns, and a save that would overwrite the file fails instead.

Why does Oda refuse to load a file that other users can read?

Oda creates the credential file so that only your user account can read it, and it refuses to load a file that other users can read. The message names the file and tells you to run chmod 600 <file> before starting again. On Windows, this check does not apply.

Can another program on my computer read my saved credentials?

Other user accounts cannot: the file is created owner-only, and on macOS and Linux a file readable beyond its owner is refused at load. Programs that run as your user account can read it, and Oda's own work on this computer runs as you. The store is a convenience, not a boundary against them.

Can I see a stored credential again?

No. Oda never shows a stored value back, and its messages never print one. What Oda reports about the store is whether a value is set and where it comes from. To change a stored credential, save a new one.

What kinds of credential does Oda keep?

Two kinds. A key: a value saved for a name, such as a model provider's key from Settings > Models, used by every request that names it. A sign-in: what Oda obtained when you signed in to a connected service, kept so later requests can use the service; signing out removes it. The sign-in conversation itself is on Authorizing services Oda connects to, and your DataMind sign-in for the server is separate; see Signing in and staying signed in.

Do stored credentials reach the model?

No. A stored credential is used to reach the service it belongs to: it travels inside the request that needs it, and it does not become part of the conversation a model reads.