Building the foundation: working directory, Python, and config in Hermes

You’ve already had your first real conversation with Hermes — a file read, a command run, something the agent did instead of just talked. This article is about making that experience solid: the working directory, the right Python when it codes, and a config that stays clean as your project grows. Think of it as turning a working prototype into something you can rely on — everything you build later in this series rests on it.

Set your working directory

By default, Hermes starts in your home folder. That’s rarely where your actual work lives. If your projects sit in a dedicated folder — say a Projects directory — you want Hermes to start there, so that every terminal command and every file action begins in the right place instead of somewhere you have to navigate away from each time.

There are two ways to set it, and they do the same thing:

• In the Desktop app settings. Open Hermes Desktop’s settings and set the working directory there — the friendliest route, no terminal needed.
• With a config command. If you prefer the command line, set it directly:

hermes config set terminal.cwd C:/Users/YourUsername/Projects

After this, every session starts in your projects folder. This isn’t housekeeping for its own sake — it’s the base you’ll build on. Automation, tools, and scheduled jobs all run relative to where the agent works, so setting this correctly now saves confusion in every later part of the series.

Tell Hermes which Python to use when coding

Here’s a Windows reality that catches people out: there isn’t one Python on your machine, there are several, and the wrong one fails silently. When you ask Hermes to write and run code, it needs to use the right one — and the way you ensure that is to tell it, at the moment you have it code.

The three Pythons you’ll encounter:

• The Microsoft Store stub. On a fresh Windows 11 machine, typing python opens the Microsoft Store instead of running anything. It’s a placeholder, not a real interpreter.
• Hermes’ own Python. Hermes ships a bundled Python inside its own folder. That one belongs to Hermes — don’t install project packages into it or you’ll break the agent itself.
• A real Python for your projects. The clean way to manage this is uv, a fast Python manager that installs and isolates a real Python for your own code, entirely separate from Hermes’.

So when you have Hermes run a script, the instruction is simple: use the project Python (through uv), not the bare python command and not Hermes’ bundled one. In practice that means running scripts with uv run python and installing packages with uv add inside the project — never a bare pip install, which lands in the wrong place.

You don’t have to memorise the mechanics. What matters is that you tell Hermes this once, clearly, when you first have it write code — and then make sure it sticks, which is the next section.

The pattern: say it, confirm it, save it

This is worth learning as a method, because it applies to far more than Python. The reliable way to give your agent a durable rule is three steps:

1. Say it. Tell Hermes the rule in plain language — for example, “when you run Python scripts, always use the uv project Python, never the bare python command or your own bundled one.”
2. Have it repeat back what it understood. Ask Hermes to restate the rule in its own words. This is the checkpoint: if it misunderstood, you catch it here, before the rule gets baked in wrong.
3. Have it save the rule. Once the understanding is correct, tell Hermes to remember it — as a memory entry or a skill. From then on it applies the rule itself, and you don’t repeat yourself every session.

This say-confirm-save loop is one of the most useful habits in the whole series. It’s how you turn a one-off correction into permanent behaviour, and you’ll use it again and again — for coding rules, for tool preferences, for the way you like things done. An agent becomes reliable not because it’s perfect out of the box, but because you teach it once and it keeps the lesson.

Keep config separate from your projects

One more piece of the foundation: keep a clean line between your project files and Hermes’ own settings. Your projects live in your projects folder. Hermes’ configuration and secrets live somewhere else entirely, in its own config location. This separation is deliberate and worth preserving.

Why it matters: when your working files and your agent’s settings are kept apart, working on a project can’t accidentally disturb your configuration. You’re not one stray command away from overwriting a setting or leaking a secret into a project folder. Two practical rules keep this clean:

• Settings go through the config command, not hand-editing. Change settings with hermes config set rather than opening the config file and editing it by hand — the command validates what you change; a hand edit can silently corrupt it.
• Secrets stay in their own file, and stay unread. API keys and tokens live in Hermes’ secrets file, separate from both your projects and your general settings. A good standing rule to give your agent: never read or print the contents of that secrets file.

Set up this way, your project work and your agent’s brain stay in their own lanes — which is exactly what you want before you start adding tools and automation that touch both.

Best practices

• Set the working directory before anything else. It’s the base every later step assumes. Do it first and you won’t have to think about it again.
• Teach coding rules the moment they come up. The first time Hermes writes code, apply the say-confirm-save loop for the Python rule. Fixing it once, permanently, beats correcting it every session.
• Never hand-edit the config file. Use hermes config set. Hand edits are the classic way to break a working setup silently.
• Keep secrets unread. Give your agent a standing rule not to read or output the secrets file. It’s a small habit that prevents accidental key leaks.

Frequently asked questions

Do I have to use the command line to set the working directory?

No. The Hermes Desktop settings screen lets you set it without touching a terminal. The hermes config set terminal.cwd command is there if you prefer the command line, but both routes do the same thing.

Why not just let Hermes use the default python command?

Because on Windows the bare python command often points at the Microsoft Store stub, which doesn’t run anything, or risks landing packages in Hermes’ own bundled Python and breaking the agent. Telling Hermes to use the uv project Python avoids both problems.

What does “have it repeat back what it understood” actually achieve?

It’s a cheap error check. If Hermes restates your rule slightly wrong, you catch the misunderstanding before it gets saved and starts causing subtle problems. Confirming understanding before saving is what makes the saved rule trustworthy.

Where exactly do settings and secrets live?

Both live inside Hermes’ own config location, separate from your projects folder — settings in its config file, secrets in a dedicated secrets file. The exact paths are managed for you; the important thing is that they’re kept apart from your working files, and that you change settings through hermes config set rather than by hand.

What’s next

The foundation is in place: Hermes works in the right folder, it knows which Python to use when it codes, and your project files and settings are cleanly separated. None of this is glamorous, but it’s what everything else sits on — and the say-confirm-save pattern you just learned is one you’ll reuse constantly.

In the next part we expand what the agent can think with. You started with one free model — that’s enough to get going, but a single model is a compromise. The next article adds more providers so your agent can match the right model to the right task: cheap and fast for routine work, stronger when the job needs it. This article is part of the Agentic AI series. If you haven’t installed Hermes yet, start with the Windows 11 install guide.