sed · troubleshooting

sed: 1: "file": invalid command code

You ran sed -i in the GNU form on macOS, where sed is the BSD version and -i needs a backup suffix as its next argument. It used your s/// command as that suffix and then tried to run your file name as a sed script.

Reproduced on GNU sed 4.9, 22 Oct 2026. Where the text says “reproduced”, the behaviour was run on that version, not taken from documentation.

First published 22 Oct 2026

New to this? Read what is actually happening first, then come back to the steps.

On this page · 8 sections

Before you start

Which machine runs the command: macOS, Linux, or a CI runner, which is usually Linux.

Run this first

step 1 of 1

sed --version

Look for GNU sed, or an illegal option error (BSD, macOS)

GNU sed answers with its version; BSD sed rejects the option, which is how you tell them apart.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

What does sed --version print?

Cause space

2 of 2 still possible

GNU-style sed -i run with macOS's BSD sedCommon
macOS-style sed -i '' run with GNU sedCommon

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Or diagnose it manually

In this order. The first command usually contains the whole answer.

Step 1
```
sed --version
```
GNU sed answers with its version; BSD sed rejects the option, which is how you tell them apart.
Look for GNU sed, or an illegal option error (BSD, macOS)

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

GNU-style sed -i run with macOS's BSD sed

Common

BSD sed requires a suffix argument after -i, so your s/// becomes the suffix and the file name becomes the script.

Confirm

sed --version

An error such as illegal option on macOS (BSD sed has no --version); GNU sed prints its version

Fix

Use the form that works on both: sed -i.bak 's/old/new/' FILE && rm FILE.bak.
On macOS only: sed -i '' 's/old/new/' FILE.
Or install GNU sed on the Mac (Homebrew calls it gsed) and use that in scripts that must behave like Linux.

macOS-style sed -i '' run with GNU sed

Common

A script fixed for macOS moved to Linux or CI: GNU sed takes '' as the suffix and your command as a file to read.

Confirm

sed --version | head -1

GNU sed, with an error naming your s/// command as a file that cannot be read

Fix

Use sed -i.bak … && rm FILE.bak, which both versions read the same way.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

Linux and macOS ship different sed programs. GNU sed (Linux) takes -i alone; BSD sed (macOS) expects -i to be followed by a backup extension, even an empty one. So a command copied from a Linux guide misreads its own arguments on a Mac, and the reverse fix breaks Linux. One form works on both.

Words used on this page

In-place edit: sed -i changes the file itself instead of printing the result.
Backup suffix: An extension for a copy of the original, for example .bak; BSD sed requires the argument, GNU sed makes it optional.
BSD and GNU: Two families of the same command-line tools: macOS ships BSD versions, Linux distributions ship GNU versions.

What is actually happeningadvanced

Reproduced on 22 October 2026 with sed -i 's/8080/9090/' FILE. On macOS the message depends on the file's first letter, because sed reads the name as a command: values.yaml gave "invalid command code v", file.txt "invalid command code f", .env "invalid command code .", while Dockerfile, deploy.yaml and nginx.conf gave "extra characters at the end of D/d/n command" and config.txt "command c expects \ followed by text". It exits 1 and the file is unchanged.

The macOS fix, sed -i '' …, breaks Linux: GNU sed 4.9 read the empty string as the suffix and then the s/// command as a file name, "sed: can't read s/8080/9090/: No such file or directory", exit 2.

sed -i.bak 's/8080/9090/' FILE worked on both and left a FILE.bak copy, which you can delete afterwards.

How to tell this is your problemsignals

Where	What you see
macOS	sed: 1: "values.yaml": invalid command code v
macOS	sed: 1: "deploy.yaml": extra characters at the end of d command
Linux, after sed -i ''	sed: can't read s/8080/9090/: No such file or directory

How to know it is actually fixed

The file changes, and running the same command on the other system does too.

Stopping it happening again

In scripts that run on both macOS and Linux, write sed -i.bak … and remove the backup, or avoid -i and write to a temporary file then move it.
Run shell scripts in CI on the same OS family your team uses locally, or test them on both.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it