starred/ntfy

Fork 0

mirror of https://github.com/binwiederhier/ntfy.git synced 2026-05-09 08:26:00 +02:00

[GH-ISSUE #1159] Bug: ntfy pub sends to the wrong topic if given as argument and present in env variable #817

New issue

Open

opened 2026-05-07 00:27:45 +02:00 by BreizhHardware · 3 comments

BreizhHardware commented

2026-05-07 00:27:45 +02:00

Owner

Originally created by @thiswillbeyourgithub on GitHub (Jul 23, 2024).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1159

🐞 Describe the bug

The topic used is from the shell env even if supplied as argument.

To reproduce:

# sends to B
ntfy pub "b" "c"
# {"id":"J7tCOcn9CSvh","time":1721725553,"expires":1721768753,"event":"message","topic":"b","message":"c"}

#same command but sends to A
NTFY_TOPIC="a" ntfy pub "b" "c"
# {"id":"q7DNCq7n","time":1721724603,"expires":1721767803,"event":"message","topic":"a","message":"b c"}

💻 Components impacted

At least ntfy-cli

💡 Screenshots and/or logs

Ntfy 2.11.0 on ubuntu

🔮 Additional context

If you have topicA and topicB, and use ntfy client with --with-config and as a command to topics : "ntfy pub topicB" then the process, receiving topicA will send a notif to topicA instead of topicB, potentially triggering an infinite loop.

I'm coding WDoc, a software that allows to do LLM based queries on heterogeneous documents as well as specifically formatted summaries.

I wanted to use ntfy to send URL from my phone to my computer running WDoc then send back the summary to my phone through another ntfy topic.

That's how I noticed the issue: ntfy seems to be using the env variable to set the topic, even if it's specified in the args, so the ntfy running on the client would send to itself in a loop.

Originally created by @thiswillbeyourgithub on GitHub (Jul 23, 2024). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1159 :lady_beetle: **Describe the bug**  The topic used is from the shell env even if supplied as argument. To reproduce: ``` shell # sends to B ntfy pub "b" "c" # {"id":"J7tCOcn9CSvh","time":1721725553,"expires":1721768753,"event":"message","topic":"b","message":"c"} #same command but sends to A NTFY_TOPIC="a" ntfy pub "b" "c" # {"id":"q7DNCq7n","time":1721724603,"expires":1721767803,"event":"message","topic":"a","message":"b c"} ``` :computer: **Components impacted**  At least ntfy-cli :bulb: **Screenshots and/or logs**  Ntfy 2.11.0 on ubuntu :crystal_ball: **Additional context**  If you have topicA and topicB, and use ntfy client with --with-config and as a command to topics : "ntfy pub topicB" then the process, receiving topicA will send a notif to topicA instead of topicB, potentially triggering an infinite loop. I'm coding [WDoc](https://github.com/thiswillbeyourgithub/WDoc), a software that allows to do LLM based queries on heterogeneous documents as well as specifically formatted summaries. I wanted to use ntfy to send URL from my phone to my computer running WDoc then send back the summary to my phone through another ntfy topic. That's how I noticed the issue: ntfy seems to be using the env variable to set the topic, even if it's specified in the args, so the ntfy running on the client would send to itself in a loop.

BreizhHardware added the

🪲 bug

label

2026-05-07 00:27:45 +02:00

BreizhHardware commented

2026-05-07 00:27:46 +02:00

Author

Owner

@wunter8 commented on GitHub (Jul 23, 2024):

I think this is working as expected. I think it's common for env variables to be used to override command arguments.

Are you saying you can't get your use case to work, though? Why are you trying to specify a topic in an env variable that is different than the topic included in the command itself?

@wunter8 commented on GitHub (Jul 23, 2024): I think this is working as expected. I think it's common for env variables to be used to override command arguments. Are you saying you can't get your use case to work, though? Why are you trying to specify a topic in an env variable that is different than the topic included in the command itself?

BreizhHardware commented

2026-05-07 00:27:46 +02:00

Author

Owner

@wunter8 commented on GitHub (Jul 23, 2024):

Oh. I think I figured out what you mean. You're saying that when the command is run from config, ntfy will automatically add env variables to the shell environment running your command. Because one of those env variables is NTFY_TOPIC, your ntfy pub command is now going to the wrong topic (it's going to the topic that triggered the command instead of going to a new topic).

I think that is expected behavior still, though. I think we want to both 1) inject env variables into the shell environment that is running your custom command (so we can act on those values, like the topic, the message contents, etc.), and 2) allow environment variables to override arguments included in the command.

I might be wrong about 2. We can see what @binwiederhier thinks.

In the meantime, I think you'll need to update the command you're running. You could write a small sh script that unset NTFY_TOPIC before running ntfy pub. Or you might be able to change your command to NTFY_TOPIC=b ntfy pub "b" "c" instead of just ntfy pub "b" "c"

Another option would be to change the NTFY_TOPIC variable that is injected to something like NTFY_SOURCE_TOPIC. Binwiederhier would also need to weigh in on this.

But now I'm starting to wonder if the other env variables (NTFY_MESSAGE, NTFY_TITLE, etc.) are also going to cause problems with the ntfy pub command...

@wunter8 commented on GitHub (Jul 23, 2024): Oh. I think I figured out what you mean. You're saying that when the command is run from config, ntfy will automatically add env variables to the shell environment running your command. Because one of those env variables is NTFY_TOPIC, your `ntfy pub` command is now going to the wrong topic (it's going to the topic that triggered the command instead of going to a new topic). I think that is expected behavior still, though. I think we want to both 1) inject env variables into the shell environment that is running your custom command (so we can act on those values, like the topic, the message contents, etc.), and 2) allow environment variables to override arguments included in the command. I might be wrong about 2. We can see what @binwiederhier thinks. In the meantime, I think you'll need to update the command you're running. You could write a small sh script that `unset NTFY_TOPIC` before running `ntfy pub`. Or you might be able to change your command to `NTFY_TOPIC=b ntfy pub "b" "c"` instead of just `ntfy pub "b" "c"` Another option would be to change the NTFY_TOPIC variable that is injected to something like NTFY_SOURCE_TOPIC. Binwiederhier would also need to weigh in on this. But now I'm starting to wonder if the other env variables (NTFY_MESSAGE, NTFY_TITLE, etc.) are also going to cause problems with the `ntfy pub` command...

BreizhHardware commented

2026-05-07 00:27:46 +02:00

Author

Owner

@thiswillbeyourgithub commented on GitHub (Jul 24, 2024):

Thanks foe the quick answers.

Oh. I think I figured out what you mean. You're saying that when the command is run from config, ntfy will automatically add env variables to the shell environment running your command. Because one of those env variables is NTFY_TOPIC, your ntfy pub command is now going to the wrong topic (it's going to the topic that triggered the command instead of going to a new topic).

Correct. Sorry if I wasn't clear!

think that is expected behavior still, though. I think we want to both 1) inject env variables into the shell environment that is running your custom command (so we can act on those values, like the topic, the message contents, etc.), and 2) allow environment variables to override arguments included in the command.
I might be wrong about 2. We can see what @binwiederhier thinks.

I agree with 1 but not with 2. I've never heard of it being common to override user args with env, overriding specific features that are implied by arguments maybe but for debugging purposes only, in which case we wouldn't want to always inject them in the env. I'm no expert though!

But now I'm starting to wonder if the other env variables (NTFY_MESSAGE, NTFY_TITLE, etc.) are also going to cause problems with the ntfy pub command...

Yeah, that would mean that ntfy pub --title titleA topicA messageA could send another message with another title to another topic...

I still think that overriding user args is unexpected. Basically to me in no way should "ntfy pub A" be sent to anything other than A. As I didn't set the env myself (it was set by ntfy sub) it took me some time to figure it out.

In the end I decided to use python requests directly but thanks for the suggestions!

Btw my code for WDoc that uses ntfy can be found there. If you think it's worth adding it to some list of project that make use of ntfy I'm definitely interested in learning where to make the PR :)

@thiswillbeyourgithub commented on GitHub (Jul 24, 2024): Thanks foe the quick answers. > Oh. I think I figured out what you mean. You're saying that when the command is run from config, ntfy will automatically add env variables to the shell environment running your command. Because one of those env variables is NTFY_TOPIC, your ntfy pub command is now going to the wrong topic (it's going to the topic that triggered the command instead of going to a new topic). Correct. Sorry if I wasn't clear! > think that is expected behavior still, though. I think we want to both 1) inject env variables into the shell environment that is running your custom command (so we can act on those values, like the topic, the message contents, etc.), and 2) allow environment variables to override arguments included in the command. > I might be wrong about 2. We can see what @binwiederhier thinks. I agree with 1 but not with 2. I've never heard of it being common to override user args with env, overriding specific features that are implied by arguments maybe but for debugging purposes only, in which case we wouldn't want to always inject them in the env. I'm no expert though! > But now I'm starting to wonder if the other env variables (NTFY_MESSAGE, NTFY_TITLE, etc.) are also going to cause problems with the ntfy pub command... Yeah, that would mean that `ntfy pub --title titleA topicA messageA` could send another message with another title to another topic... I still think that overriding user args is unexpected. Basically to me in no way should "ntfy pub A" be sent to anything other than A. As I didn't set the env myself (it was set by ntfy sub) it took me some time to figure it out. In the end I decided to use python requests directly but thanks for the suggestions! Btw my code for [WDoc](https://github.com/thiswillbeyourgithub/WDoc/tree/dev) that uses ntfy can be found [there](https://github.com/thiswillbeyourgithub/WDoc/tree/dev/examples/NtfySummarizer). If you think it's worth adding it to some list of project that make use of ntfy I'm definitely interested in learning where to make the PR :)

BreizhHardware referenced this issue

2026-05-07 01:02:05 +02:00

[PR #817] [MERGED] fix(web-push): re-init i18n on each sw message #1435