Error creating task Invalid request: AbsolutePathBuf deserialized without a base path

A request was rejected at its own boundary, before anything ran. No model was called, no tokens were produced, nothing was billed, and no task exists. That rules out an authentication problem, a quota or rate limit, and a capacity failure — all of which arrive as HTTP responses with status codes attached. What failed here is validation of a value inside the payload: a field that is required to hold an absolute path was handed something that was not one, with no context available to make it one.

The message is three clauses, and each one narrows the search

“Error creating task” tells you where in the lifecycle you are. Task creation was attempted and did not get far enough to produce a task. Nothing is half-created and there is nothing to cancel or clean up — the single piece of good news on this page.

“Invalid request” tells you the verdict is about content, not transport. The bytes arrived intact and were understood well enough to be judged wrong. A network fault would not be able to produce this sentence.

“AbsolutePathBuf deserialized without a base path” is the fault itself. A value whose type guarantees absoluteness was read out of serialized data. The input was not absolute, and the reader had no base directory to resolve it against, so no value of that type could be constructed. The type name is an internal detail of the tool and may well be renamed; the class of failure it describes will not change, and that class is the useful thing.

A relative path is not a value — it is a value plus a context

Here is the judgement worth carrying away, because it explains why this error tends to appear suddenly on a setup that worked for months.

./out, src, and ~/projects/app are not locations. They are instructions for computing a location, and the missing input is a working directory. A working directory does not survive serialization. Write a relative path into a config file, a saved setting, a job definition, or a message on a wire, and you have stored half of an expression. Whether it still means anything depends entirely on where the reader happens to be standing, and readers frequently stand somewhere you never considered: a background service starts in a directory chosen by the service manager, a scheduled task starts in a system directory, an editor extension starts in whatever the editor inherited, and a process launched from a desktop icon starts wherever the launcher decided.

So the bug is rarely the path. The bug is the boundary the path crossed, and the fix is to make the value complete on the side that still knows the context.

`~` is relative, and so are several things that look absolute

Before hunting through your setup, look at the first characters of every path you can find. These are the shapes that produce this error, each with the observation that identifies it.

A leading ~ — tilde is shell expansion, not filesystem syntax. Type ~/work at a prompt and the shell replaces it before the program ever sees it. Write ~/work into a configuration file and the program reads a literal tilde, which is a relative path starting with an unusual character. This is the single most common cause and the one people resist, because the value “obviously” points at their home directory.
A leading . or .., or a bare name — unambiguously relative. Ask which directory it was written in, then ask whether the reader runs there.
An unexpanded variable — $HOME/x or %USERPROFILE%\x stored as text rather than as its expansion. Same failure as the tilde: expansion is the shell’s job, and no shell is involved when a file is read directly.
An empty or collapsed value — a path assembled from a variable that was not set in the failing process’s environment, leaving something that is relative by accident. The tell is a path with a doubled separator or a suspiciously short value.
On Windows, drive-relative and root-relative forms — C:work means “work, relative to the current directory on drive C”, and \work means “root of the current drive”. Both look absolute and neither is. A strict absolute-path type rejects them.

Is retrying useful?

No. The same bytes deserialize the same way every time, and nothing about the second attempt supplies the base directory the first one lacked.

There is a second reason, and it is the one that saves you from writing a retry wrapper. This failed before a request was sent, so none of the usual retry machinery applies: automatic retries operate on HTTP outcomes — connection errors, 408, 409, 429, 5xx — and there is no HTTP outcome here. That is also why you cannot produce a request id for this error, which is worth knowing before you open a support ticket expecting to quote one.

If the error is intermittent, do not treat that as evidence that retrying works. An intermittent version of this means the working directory differs between runs — the same command invoked from two places, or a job that sometimes starts elsewhere. That is a much more useful finding than a flaky network would be, and the next section turns it into a test.

Finding the value without guessing at internals

Each of these is a measurement, not a theory, and none of them requires knowing anything about the tool’s internal configuration model.

Run the identical command from a different working directory. If the error appears in one place and not another, something in the path is being resolved against the current directory. That single observation converts an opaque type error into a search for a relative value.

Run it from a directory with no project configuration — a temporary directory with nothing in it. If the failure disappears, the offending value lives in a per-project file, not in your invocation or your user settings.

Move settings files aside, one level at a time, and retry. Project-level first, then user-level. The level at which the error stops is the file containing the value. Put them back afterwards; this is a bisection, not a fix.

Ask what launched it. If an editor, an automation script, a scheduler, or a CI job is creating the task, it is passing paths programmatically. Log exactly what it passes, in that process, before it hands off. A path that is correct in your terminal and relative in the caller is the whole failure.

Ask what changed. This error commonly starts after a project directory is moved or renamed, after settings are synced between machines, or after a config file is edited by hand. Configuration written on one machine and read on another is the classic producer of a path that used to resolve and now does not.

Fixes, attached to the observation that selects them

A stored value starts with ~, ., or a bare name — replace it with a fully expanded absolute path. Let the shell expand it and paste the result; do not store the expression.
A caller passes the path — make the caller absolutize it against a base it knows, before handing it over. The caller is the last participant that still has the context, and giving it away is the actual defect.
The config is shared or synced between machines — machine-specific absolute paths do not belong in a file that travels. Supply them per machine, from the environment of the process that runs there.
A service, scheduler, or CI job is the caller — set the working directory explicitly in the job definition rather than assuming one. Processes started by system components do not inherit your shell’s notion of “here”.
Nothing you control contains a relative path — capture the exact string and the tool version and report it. A value serialized without a base can also be a defect on the producing side, and the giveaway is precisely that you searched everything you own and found nothing relative.

One boundary this page will not cross: which named setting holds the path in this tool is part of its own configuration surface, and that surface changes. Take key names and file locations from the current official Codex documentation rather than from any third-party page, including this one. The mechanical tests above are stable; the key names are not, and a stale key name would send you to edit something that no longer exists.

How to confirm it is fixed

Re-run the exact command that failed, from the exact directory it failed in. Then run it again from a completely different directory. Both must succeed — that is the falsifiable part. A single success from your project root is indistinguishable from a relative path that happened to resolve there, which is the state you were already in.

Then confirm the task is actually created and does its work, rather than confirming only that the message stopped. A validation error disappearing can mean the value became valid, or it can mean the code path stopped being reached.

If a service or scheduled job was the caller, restart it so any edited configuration is genuinely re-read, and verify in that context. Testing in your terminal after fixing a service’s configuration proves something about your terminal.

The closest neighbour is another Codex-side record failing a structural requirement rather than a permission one: codex/sandbox-state-meta missing sandboxPolicy reaches a consumer without a required field, and the instinct to loosen settings is wrong there for the same reason that creating a directory is wrong here.

If the request is rejected for who you are rather than what it contains, no eligible ChatGPT workspaces found is the account-side rejection that also arrives as an invalid request and has nothing to do with your filesystem.

And when a path error names a directory that genuinely is not there, rather than one that could not be made absolute, ENOENT: no such file or directory, scandir is the page for that shape — the distinction being whether the path was resolved and missing, or never resolved at all.

Not sure yet which layer you are on? The AI coding error triage tool separates validation failures like this one from transport and capacity failures by the signals used above: whether a status code exists, whether a request id exists, and whether anything was retried before you saw it.