I've accepted this so many times that firewall should already remember it.

Do you want the application "AppName.app" to accept incoming network connections?

Clicking Deny may limit the application's behavior. This setting can be changed in the Firewall pane of Security preferences.

Deny | Allow

For example, I get it for Eclipse when starting my java programs in debugging mode. Sometimes this dialog is displayed only very shortly, like half second, and disappears. I also get it for iTunes (when I enable sharing my library), and other programs, even though I have them listed in Firewall preferences panel (adv. settings).

  • What version of OSX are you using? Oct 18, 2010 at 14:58
  • @Martin: added snow-leopard tag. I use latest and greatest 1.6.4. Oct 18, 2010 at 15:19
  • The behavior is very odd to my knowledge. The firewall looks at the app signature to recognize it, so any change in the app, means it might no longer be recognized and thus will cause a new prompt. Leopard was more prone to this than 10.6, however it still happens from what you’re telling. Oct 18, 2010 at 15:27
  • I used to see this all the time with VirtualBox on Snow Leopard. I'd love to hear an explanation for it as well.
    – Ben Wyatt
    Oct 18, 2010 at 15:32
  • 1
    Very annoying. I see the popup a couple of times per day while working in Eclipse. It only shows up for a sub-second or so. This happens on Mountain Lion with Eclipse Juno SR2.
    – Gunnar
    Jun 7, 2013 at 15:19

14 Answers 14

sudo codesign --force --deep --sign - /path/to/application.app

I've never had to create a certificate using this method.

If that doesn't help, try without --deep and without the trailing slash:

sudo codesign --force --sign - /path/to/application.app

Note, just to make it clearer: After having applied the signature, start the app, accept incoming connections one last time, then quit and start again to verify that the request is gone.

  • 6
    I know because I did it? I'm not sure exactly what you're asking for... using that method I was able to get rid of the 'accept incoming notifications' pop-up (though after signing you will be asked one final time, and then no more). It's worked for me for Spotify and AppCode. If you need info read the man page? edit: I'm using Yosemite GM Candidate v3.0 if that helps you.
    – ahall
    Oct 16, 2014 at 14:54
  • 4
    I would like to amend one small detail: the app that needs to be addressed under /path/to/app must contain the .app ending, i. e.: /path/to/exampleapp.app.
    – user103234
    Dec 3, 2014 at 8:22
  • 4
    @IconDaemon The use of - after --sign means that "ad-hoc signing" is used; there's no need to have a cert to use that command. I don't understand why this would contradict the use of the terminal. Run man codesign to see the explanation.
    – Mike
    Dec 21, 2014 at 4:22
  • 3
    Simple, and works. Much better than accepted answer as I don't want to delete plist files.
    – Justin
    Dec 29, 2014 at 17:26
  • 2
    sudo codesign --force --sign - /path/to/application.app has worked for me, but not the variation suggested by the author. I wonder if --deep or the leading slash was a problem.
    – Jose Alban
    Jul 10, 2015 at 12:49

While RedYeti's link is useful, just to save a few clicks for others let me recap how to generate a code-signing cert and to use it for code (re-)signing:

  1. Create your own code signing cert:

    • In Keychain Access, Keychain Access > Certificate Assistant > Create a certificate. This launches the Certificate Assistant:

    • Name: Enter some arbitrary string here that you can remember. Avoid spaces otherwise you'll need to escape the cert's name when using codesign from the command line.

    • Identity type: Self Signed Root

    • Certificate Type: Code Signing

    • Check the box "Let me override defaults", this is quite important

    • Serial number: 1 (OK as long as the cert name/serial no. combination is unique)

    • Validity Period: 3650 (gives you 10 years)

    • Email, Name, etc. fill out as you wish.

    • Key pair info: set to RSA, 2048 bits. Does not really matter IMHO.

    • From "Key usage extension" up to "Subject Alternate Name Extension": accept the defaults.

    • Location: login keychain.

    • Once it is created, set to "Always trust" in the Login keychain: right-click on the certificate, choose "Get Info", and in the "Trust" section, set "When using this certificate" to "Always trust".

  2. Re-signing an app: codesign -f --deep -s <certname> /path/to/app

  3. Verify that it worked: codesign -dvvvv /path/to/app


UPDATE: People asked me why this is "not working" in macOS 10.14 "Mojave". Now that I have finally upgraded :-), here's what I learned.

Basically, don't use a self-signed certificate for code signing. Generate a certificate using your Apple ID in Xcode instead. To recap the steps briefly:

In Xcode > Preferences > Accounts, select your Apple developer ID, click "Manage Certificates", select the "+" in the bottom left corner, it offers you the option "Apple Development". Select that, this will make a certificate for you. By Ctrl-clicking on the new certificate you can export it (in .p12 format), and by open-ing that .p12 file it gets loaded into your Login keychain.

You will see that this certificate is valid for a year, "Issued by: Apple Worldwide Developer Relations Certification Authority". I suspect that is trustworthier than a self-signed certificate.

Now you can sign your app as before with codesign -f -s <apple_ID> /path/to/prog. I tried it with a simple binary (compiled from hello.c :-) ), and it could be verified with codesign -v.

I haven't tried it with Python packages yet, so I have no advice to people who mentioned in their comments that this cannot sign "python.app".

  • 4
    Thank you! This is the only solution that got rid of the firewall nag dialogs for me. I'm running OSX 10.10 Yosemite.
    – Jason
    Jun 17, 2014 at 22:56
  • 1
    very nice! easy for developers who already have a cert, too!
    – cwd
    Jul 29, 2014 at 17:57
  • 1
    a side note : I have maximized the Validity Period to 7300 (days), that is 20 years. I found with some try that this is the max number that the input box accept (at least on OSX Yosemite 10.10.3) - very well, kudos !
    – DavAlPi
    Apr 13, 2015 at 16:17
  • ahall's answer is much simpler and worked for me on OS X 10.10
    – n1000
    May 8, 2015 at 9:12
  • Didn't work for me on OS X 10.11.1 (15B42) Oct 28, 2015 at 16:46

There are two options here:

  1. You can simply select "Allow All" in your firewall, or simply turn it off.
  2. You can remove the apps from the list, delete the plist file for those apps, run them, and then add them to the list. The plist is responsible for a lot of behaviors and I'm willing to bet either an upgrade to the OS or the app can cause the "link" to break.

About plist files... A plist is a special kind of text file that contains properties the application and other resources, typically the OS, use to retain and reuse information needed to run the application. plist is a file type and has many uses, typically storing user preferences, but, essentially, it is an XML file. You can look to see if there are any caches, which are typically plist files, for the applications in question in /Library/Caches and /System/Library/Caches. There is also one in ~/Library/Caches/ but bad things can happen when mucking around in there, so just leave it alone. The system goes into those folders for a wide variety of reasons, and I usually clean out the first two folders I listed completely about once a month.

  • 3
    Can you please explain what you mean by "delete the plist file for those apps"? Oct 18, 2010 at 18:05
  • 2
    the plist files contain the application settings among other things (and it’s safe to delete them, but always make a copy just in case). Any Cocoa app must be programmed to re-create its own plist should the file “disappear”. The plist for apps are usually located in /Users/your_user/Library/Preferences. The files end with .plist extension and usually have names like: “com.company.appname.plist” e.g: com.adobe.Phosothop.plist . You can move them to your desktop and launch the application to “re-create” it. Oct 18, 2010 at 21:36
  • Are the ~s in the file paths above referencing the current user's home folder or the root directory?
    – user5118
    Feb 2, 2012 at 17:55
  • 2
    Downvoted since this is not really an option in many cases. user465139's comment is more appropriate. Though still a security risk--it is at least less than allowing all apps in/out.
    – sholsinger
    Sep 13, 2014 at 23:03
  • 1
    agree with @sholsinger on this one, just stumbling on this for Mavericks + PHPStorm and the self-signing alternative is easy, fast & works. This plist business is kinda messy.
    – Alex Weber
    Sep 14, 2015 at 19:12

This relates to whether the app is signed or not. If it's not signed, the preference won't be remembered.

To see if an app is signed do this in Terminal:

cd path/to/your/app
codesign -vvv Eclipse.app/

For Eclipse - mine says it's not signed at all. I can't comment further on how to sign the app since I've not bothered to do that but this answer on superuser covers it:


  • 3
    While ahall's answer gives a solution, this answer explains why. If merged, it would be the perfect answer.
    – not2savvy
    May 16, 2017 at 11:09

If you're programming in Go:

http.ListenAndServe("localhost:8080", nil)

Instead of:

http.ListenAndServe(":8080", nil)

  • Welcome to Ask Different. Can you elaborate on how your answer relates to the question and where that line of code should be used?
    – jaume
    Sep 19, 2020 at 5:59
  • 3
    The above answer is for Go developers on macOS. It indeed works a treat and stops all the annoying popup every time the binary restarts (which is a lot throughout the day). It might not make a lot of sense without context but it's a great answer for go devs.
    – keyle
    Jan 23, 2021 at 1:00
  • 1
    Thank you! This was the answer I was searching for. May 1, 2021 at 5:38
  • 2
    This isn't actually just a go answer. It relates to whether you're listening on all network interfaces or just on the localhost interface. So in any language, if you use the default listen, it usually means "listen on all interfaces", which means more likely firewall interaction.
    – rfay
    Jun 19, 2021 at 19:09

Just a note though, if you are using a Virtual environment, be sure to sign the app that is being used for the environment. I know this is obvious, but needed to be said nevertheless.

  • thanks a lot but instead of an app, how would I sign a python version (say python3.6) in a conda environment?
    – Agile Bean
    Dec 4, 2018 at 13:58

I got help in Sayan Mohsin's answer, and I believe it's more generic than go.

I had this issue with a piece of software that does not need to allow connections from the outside, only from my machine. Such software does not need to be signed to avoid this warning: it only needs to explicitly listen on localhost only.

Depending on your environment, setting a host restriction will be done differently. In my case, I was working with an nginx server, and changing its configuration from listen 8080 to listen was enough to fix it.

If this is also your case, you should definitely check out if your server exposes a way to setup host restriction and set it up to localhost or


If you're looking for a way to disable this alert for the iOS Simulator, you can use this script from Tom Soderling:


# Script to disable the iOS Simulator app from showing the "Do you want the application xxxx to accept incoming network connections?" pop-up every time the app is run

echo "> Enter password to temporarily shut firewall off"
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate off

echo "> Add Xcode as a firewall exception"
/usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/Xcode.app/Contents/MacOS/Xcode

echo "> Add iOS Simulator as a firewall exception"
/usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app/Contents/MacOS/Simulator

echo "> Re-enable firewall"
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on

exit 0

Note that you have to run it again after every restart. You can do that with launchd by following these instructions. Be sure to specify this:


I appreciate that this is an old Q & A, but it was the first hit on google for me when I had the same problem. Just wanted to add something for others that may land here.

In order to execute any of the codesign commands outlined here, it is necessary to have the xcode command line tools installed. Without these, one gets an error message:

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

To fix this, install the tools with:

xcode-select install

I would've commented on ahall's post, but I don't have the reputation points to do so.


My situation involves two copies of Eclipse installed on MacOS Mojave 10.14.5. The first copy was authorised with the MacOS firewall. The second copy would always present the "accept incoming connections" prompt. Choosing "Accept" would continue to present the message after each reboot, apparently the firewall setting was not updated.

The solution was to open MacOS System Preferences -> Security & Privacy -> Firewall, unlock the screen, Firewall Options. Select Eclipse.app "Allow incoming connections" and remove it with the "-" button. The next time I selected "Allow" to the Eclipse "accept incoming connections" prompt was the last.

  • I experienced the same problem after upgrading to MacOS 11.0.1 Big Sur and Eclipse 2020-09. The message was a bit different; "Do you want the application “Eclipse.app” to accept incoming network connections?" but the solution is the same.
    – Les Grieve
    Nov 18, 2020 at 12:12

You can avoid triggering the firewall by only binding to localhost instead of all interfaces, if you don't need to have your application accessible over the network.

Here's an example using python3's build in web server, but the concept works across all languages:

# Triggers firewall (unless you gave permission in the past)
python -m http.server 8080

# localhost only, no firewall popup
python -m http.server --bind localhost 8080
  • the OP wanted to avoid the dialogue for requests they accepted earlier. Don‘t think that binding all ports helps here.
    – nohillside
    Sep 12, 2023 at 10:37
  • OP gets firewall popups because he binds to external interfaces. Only binding to a local interface will avoid triggering the firewall. The approach of accepting the request does not work because the application he is developing is constantly changing during development. So MacOS does not consider it to be the same application he already allowed. Sep 12, 2023 at 12:26
  • They also get it for iTunes.
    – nohillside
    Sep 12, 2023 at 13:29
  • 1
    Thanks! I've learned some time ago that this really does avoid the problem with local development, and use this technique eg. in unit tests. Sep 13, 2023 at 8:14

I got this dialogue box (Canon ccpd) everytime after starting my computer. Open firewall > security and privacy > unlock to enable changes > click on button "Enable stealth mode" > click button "Block all incoming connections".

No more irrating dialogue box from Canon printer driver after that.

  • 1
    But the app won't work...
    – not2savvy
    May 16, 2017 at 11:10

I tried all the above in Mac 10.13 and nothing worked.

In the end I wrote a script that ran at logout attached to login hook that turned off firewall so when logged in it no longer needed permission then using delayedlauncher ran another script that turned on firewall.

All good now

  • 2
    Welcome to Ask Different! You might want to share your script so that other users can profit from your solution as well.
    – Glorfindel
    Dec 22, 2018 at 14:47

The solution for me was to just disable the firewall completely. It's extremely common to create web-enabled pieces of software that are of course unsigned because you're compiling them natively.

Open the spotlight with CMD + Spacebar and search "privacy" and select "Security and Privacy". Then switch to the "Firewall" tab and disable the firewall there.

  • 3
    That seems like a pretty poor solution for most people unless they know what they are doing. Firewalls are there for good reason - even on Macs.
    – RedYeti
    Mar 16, 2017 at 10:00
  • I think you meant "Firewalls are annoying - even on macs". Not everyone is uneducated running around on open wifi networks at airports with all their ports open downloading viruses off malware distribution sites. My answer correctly fixes the problem and gets around Apple's stupidly annoying popup boxes. Every time you recompile a binary that uses the network you get the popup which is absolutely inexcusable. The popup is just another annoying way Apple tries to baby uneducated people while leaving developers high and dry. Mar 16, 2017 at 21:01
  • 2
    I agree - not everyone is uneducated. However on this subject the vast majority of people are. Even those who aren't should know better than to take out the main network security component. At the very least, warning people of the possible consequences would have been good. Simply turning off the firewall I'd not count as a "fix" but a very hacky work-around.
    – RedYeti
    Mar 17, 2017 at 8:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .