Gmail node issue with cc/bcc

Describe the problem/error/question

I have a n8n Gmail read node that runs every minute and creates emails in my database. Some of the returned fields are thread id, message id, from, cc, bcc, message, etc.

Then I have also a different n8n integration to respond to a Gmail message using the n8n “Gmail Thread reply” sending the thread id and message id as parameters to the webhook that I previously created from the “read” workflow.

Everything works great, but what I have found an issue/bug. Let’s say a customer started a new conversation sending a bcc and cc in the original first message.

If I want to remove a cc/bcc from the original email, then it just doesn’t care about the parameters. It emails anyway to all the original cc/bcc, making it impossible to remove a cc/bcc from the original email.


I had to move to the action “Reply to a message” using only the message id, and forcing the options like this:


Which makes sure to always just respond to cc/bcc in the fields… but I really don’t like this method because the customer just receives the email without being able to access or see the full thread of the conversation so they really don’t know to what I am responding to if they sent multiple emails before receiving a response.

Any ideas? Is this a bug?

Information on your n8n setup

  • n8n version: 1.16.0
  • Database (default: SQLite): Postgresql
  • n8n EXECUTIONS_PROCESS setting (default: own, main): Queue
  • Running n8n via (Docker, npm, n8n cloud, desktop app): docker image + Railway
  • Operating system: -

Hey @yukyo,

This is an interesting one, I will check the API docs for GMail to see what it says. Interestingly though the BCC field shouldn’t matter as by design you should only see that if you were in the BCC field so if you were to reply to all the other folk in the BCC list should never get that message.

Yeah sorry @Jon I didn’t explain myself properly with the bcc. Yeah, the bcc is something that we add from our end in our website.

Example, this is an email received and created using n8n and we add data in our database to display it in our website:

As you can see in the original email received from that address, it contained two CCed addresses… But let’s say I want to just RESPOND to the original email sender, the address in “TO” but remove the CC addresses, I can do that by deleting those items from the entry in my DB and then sending the API to my n8n webhook with the CC/BCC fields empty. However, even if I do that, the n8n respond thread action WILL CC those two addresses because they were created in the original email… that’s what the actual issue is.


Hey @yukyo,

You may have tried this already but in Thread > Reply there is an options section at the bottom, I just noticed we have a Reply to Sender Only option I believe this may do what you are after.


@Jon thanks, but yes and no.

What if I want to add a different CC? Or couple of them? OR just remove one of the two that I received in the original CCed email?

Then I woudn’t be able to use that toggle…
Which is what is causing me an issue, if I want to remove all then yeah the toggle button would work, but if I want to add different ones from the original email or just remove one, etc, then it won’t work.

Ideally CC and BCC fields should only be activated when I pass email values in these fields and not ALWAYS from the original email… which is how it is right now.


Hey @yukyo,

If you wanted to change the CC then wouldn’t not setting the reply to sender only option and specifying your CC recipients do the job?

From what I understand there are 3 different ways to use this option…

Reply to Thread with no options - This will reply to sender and CC
Reply to Thread with Reply to Sender Only - This will reply only to the sender
Reply to Thread with CC - This will reply to the sender and whoever you include in the CC

If you wanted to add or remove from the existing list you would need to know what they are to change them so I suspect adding the CC field wouldn’t be an issue :thinking:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.