Skip to main content
Every repository can have its own:
The root is git’s toplevel — the same as git rev-parse --show-toplevel. It is not created by TYBA; absent is the normal case. It is versioned along with the project, and that is where the problem the next section solves lives.

​
The whole file

.tyba/config.toml

​
agent.default

Three values are recognized: Any other value is ignored silently. default = "cursor" raises no error and does nothing.
Since Claude Code is already the product’s default, in practice default = "claude" changes nothing. The field only has a visible effect with "codex", and even then only when codex is in your PATH.

​
agent.env.allow

Agent sessions do not inherit your environment. They receive a fixed baseline and nothing more:
Your tokens, DATABASE_URL, API keys — none of that reaches the agent by default. If the project needs some variable, list it here:
The names must be valid identifiers ([A-Za-z_][A-Za-z0-9_]*).
The allowlist only adds on top of the baseline — it never overwrites. Listing PATH does not hijack the agent’s PATH: TYBA forces its own afterwards, and a hostile repository cannot point the agent’s binary somewhere else.

​
A new file is worth nothing until you approve it

This is the most important design on the page, and it exists for a concrete reason: you clone third-party repositories. If a versioned .tyba/config.toml took effect automatically, any repository could ask for your AWS_SECRET_ACCESS_KEY in the agent’s environment just because you opened the project. So:
1

TYBA computes the file's hash

A SHA-256 of the exact content.
2

It asks you

What that file is asking for — default agent and which variables — before applying anything.
3

Your consent applies to that hash, and only that one

As long as the file doesn’t change, it holds.
4

One different byte takes the consent down

You changed it, a git pull touched it, you switched branches — the hash changes, the consent dies, and TYBA asks again.
Without consent, the file is as if it didn’t exist. The session starts normally, with the fixed baseline of six variables.
This means a correct .tyba/config.toml does not work on its own on a new machine. You cloned the project on a new computer, the consent didn’t come along — it is yours, local, per machine. You will be asked again. That is the intended behavior.

​
A broken file is ignored, it doesn’t take things down

Unlike the user config, a repository’s .tyba/config.toml with invalid TOML does not stop the session from starting. It is simply ignored, and you are left with the fixed baseline. The asymmetry is intentional. The user config is yours — if it’s broken, it’s your mistake and you want to know now. The repository config may have come from anyone, and a malformed file in a cloned repository should not be able to lock up your tool.

​
See also