Is there any easy way to append command line arguments to an application on a Mac? For example, to run Opera in kiosk mode or to use a different profile in Firefox, I can type

$ /Applications/Opera.app/Contents/MacOS/Opera -kioskmode
$ /Applications/Firefox.app/Contents/MacOS/firefox -P profilename -no-remote

In Windows I can append the arguments to the shortcut properties, but since Macs don't use shortcut per se and run the applications directly, this isn't possible.

I have found that launching the applications through bash or Applescript partially works:

# Bash
/Applications/Firefox.app/Contents/MacOS/firefox -P default -no-remote

# Applescript    
do shell script "exec /Applications/Opera.app/Contents/MacOS/Opera -kioskmode"

I can make these executable and assign an icon and everything works great except that when I run either of these pseudo programs, either a terminal window or an Applescript icon remains open as long as the application is open. Presumably, using the Applescript command open would avoid this, but since I'm not running the application as it is packaged (just /Applications/Firefox), it doesn't work.

So, is there a better way to run applications with command line arguments? If not, is there a way to prevent a persistent terminal session or Applescript icon from staying open while the application is open?


According to a Mozilla Wiki page, it's best to use a script to run the application with arguments. Adding a & to the end of the script kills the persistent Terminal window. The only annoyance now is that it opens a dead, logged out Terminal window (which is better than the persistent one, but still...)

/Applications/Firefox.app/Contents/MacOS/firefox -P default -no-remote &
  • 2
    I'm still hoping for better answers on this one...
    – cregox
    Oct 30, 2010 at 2:34
  • 1
    When you run a job with & it still belongs to the Terminal, you can fix that by adding the line disown %/Applications/Firefox.app/Contents/MacOS/firefox after you run it, then you can safely close the Terminal, using AppleScript.
    – ocodo
    Jan 22, 2011 at 13:00
  • look for Daniel's answer - it's the most complete and perfect for today (OSX 10.6.2 +).
    – cregox
    Jan 26, 2011 at 19:03
  • 2
    FUTURE GOOGLERS: the open command has an --args argument: open -a FireFox --args -ProfileManager does exactly what you want. Apr 14, 2021 at 12:26

10 Answers 10


This answer is obsolete.

Refer to other answers for modern Mac OS.

Here's my best solution: Create an Applescript with:

do shell script "/Applications/Firefox.app/Contents/MacOS/firefox -P default -no-remote & killall Firefox.app"

And save it as an application.

You can put whatever application with whatever args in the first part. The part after the & needs to kill whatever you have named your script + .app. You'll see the script app flash up in the dock, but it will then disappear.

Note: The script will not work properly when run from Script Editor, only when run from the script application you have created.

  • It almost works. It's still waiting for the Firefox instance to be done until it runs killall, so it calls the debugger when I close Firefox, and the script app still doesn't go away. Hmmm...
    – Andrew
    Aug 1, 2009 at 12:10
  • That's weird. Are you saving it as an App then double clicking the App? It won't work when run from Script Editor.
    – MJeffryes
    Aug 1, 2009 at 12:14
  • Also, I notice I put a newline in before the &. Remove the newline if you have it
    – MJeffryes
    Aug 1, 2009 at 12:16
  • no need for &killall here at Snow Leopard 10.6.x - but also couldn't find any way to make the app kill it self as soon as executing.
    – cregox
    Oct 30, 2010 at 2:52
  • 2
    @Pacerier Check the dates on this answer.
    – MJeffryes
    Dec 16, 2017 at 12:55

Starting in OS X 10.6.2, the open command can pass arguments to the application it opens by way of the --args flag. An AppleScript to use it looks like this:

do shell script "open -a /Applications/Firefox.app --args -P default -no-remote"

That should give you all the behavior you want.

  • 1
    "man open", and there it is! worked like a charm. --args flag and then your arguments. Oct 8, 2017 at 16:21
  • 2
    I tried --args with Chrome and it doesn't work. It will only work for the first instance. If you try to run two --user-data-dir concurrently, you can't do it with open but must run it by the old /applications... method. Anyone know why the fuck does --args not work?
    – Pacerier
    Dec 15, 2017 at 22:39
  • 2
    @Pacerier, "open -n" Jul 18, 2018 at 21:18
  • To add to this, you can create the script in Script Editor and then save as application.
    – Kevin C.
    Jan 5, 2019 at 21:06
  • 1
    As @SimonWright replied but didn't explain the -n flag opens a new instance of the application.
    – Jerinaw
    Dec 2, 2020 at 1:32

Open Automator and create an Application with a single Run Shell Script action:

 /Applications/Firefox.app/Contents/MacOS/firefox-bin -here-some-args &

This application will launch Firefox and quit instantly, leaving only Firefox running.

Alternatively, create an application using AppleScript Editor with the following AppleScript code:

do shell script "open -a '/Users/danielbeck/Applications/Firefox.app' --args -ProfileManager"

Both work fine and don't keep either Terminal or a script application running for more than a second or so. Using Automator, you can even create a Service if you choose so.

  • 2
    Just keep in mind the open --args was implemented in 10.6.2, as Bob already mentioned.
    – cregox
    Jan 26, 2011 at 19:04
  • Using it for: open eclipse.app -n to open a second Eclipse workspace. Very handy. Thanks!
    – jonalv
    Nov 1, 2011 at 9:19
  • Couldn't get it to work in Automator with "Run Shell Script" action in MacOS 10.14. I ended up having success with the AppleScript, though.
    – Kevin C.
    Jan 5, 2019 at 21:06
  • 1
    Works great for me on Catalina.
    – jerclarke
    Jan 2, 2020 at 16:45
  • 1
    @KevinC. This didn't work for you? /Applications/Firefox.app/Contents/MacOS/firefox-bin -ProfileManager & I did a test run in Automator and that worked. Then I saved it to my Applications folder as a .app file and launched it from there - that worked too. I'm also running macOS 10.14 (Mojave).
    – Mentalist
    Jul 7, 2020 at 13:44

The open command has an optional --args argument that's value will be passed on to the opened application as arguments. For example:

open /Applications/TextEdit.app --args example.txt
  • 2
    This is the correct answer. Apr 14, 2021 at 12:21
  • 2
    This is still the correct answer.
    – nirazul
    Oct 7, 2022 at 10:38
  • Works like a charm Jan 4, 2023 at 14:29

This is a old discussion, but still comes up on Google searches, so I thought I'd add a couple of ¢.

It's probably better to use a "bundle identifier" rather than absolute path to the executable:

open -b com.google.Chrome --args --profile-directory="Profile 1"

Or in an Apple Script:

do shell script "open -b com.google.Chrome --args --profile-directory='Profile 1'"

What I have not figured out yet is how to open a new instance/window with a different profile once the first one is already open. (If I run the AppleScript above, then another with "Profile 2", then Chrome will still just open another window as "Profile 1"). :(

  • Is -b functionally equal to -a? How are they different?
    – Pacerier
    Dec 15, 2017 at 22:52

It is not necessary (as some other answers have suggested) to use killall (or similar) to kill the parent AppleScript application process (“applet”) in this scenario. It can even have untoward side effects if the name/pattern given to killall matches more than just the parent applet process (e.g. other, concurrently running AppleScript applications (if using “applet” as the pattern)).

Something like kill $PPID might be more reasonable, but we may not want to assume that the applet of an AppleScript application is always the immediate parent of the shell started by do shell script. Luckily, there is a perfectly reasonable way to do what you need.

Per TN2065 (under “I want to start a background server process; how do I make do shell script not wait until the command completes?”), the proper method is to redirect stdout and stderr and have the shell run the program in the background.

Use Script Editor to save the following program as an AppleScript application:

do shell script ¬
    "/Applications/Firefox.app/Contents/MacOS/firefox-bin \\
        -P default -no-remote \\
        >/dev/null 2>&1 &"

(functional line breaks added to keep it “narrow”; delete the ¬ and \\ and put it all on one long line if you like)

It will run long enough to start Firefox and will exit cleanly while Firefox continues to run.

The redirection is required because not only does do shell script wait for its immediate child (the shell) to exit, but it also waits for (all instances of) the writable ends of the pipes it creates for the shell’s stdout and stderr to be closed. The shell’s stdout and stderr (do shell script’s pipes) are inherited by the programs it runs without redirection (even ones run in the background with &); the redirection ensures that the shell is the last one to hold the writable ends of the pipes. Thus, do shell script will return immediately after the shell exits, allowing the AppleScript application itself to exit (since the do shell script is the last expression in the AppleScript program).

The other answers that use open inside do shell script work because open (actually LaunchServices) does the equivalent work of backgrounding the resulting program and sending its stdout and stderr elsewhere.

  • this is very interesting. I wonder if it works prior to 10.6.2 ... but I still think using open --args looks cleaner. is there any drawback on using any of them?
    – cregox
    Mar 14, 2011 at 0:49
  • 2
    I know this method works in 10.4. My impression is that do shell script has always worked like this (it was added to the Standard Additions OSAX in AppleScript 1.7, which came with Mac OS X 10.1). If you are willing to assume 10.6, then open --args is probably fine. Mar 14, 2011 at 3:01
  • @ChrisJohnsen, Link down........
    – Pacerier
    Dec 15, 2017 at 22:43


do shell script "/Applications/Google\\ Chrome.app/Contents/MacOS/Google\\ Chrome --incognito & killall applet"

Two points there.

  1. The space is escaped by a backslash which is escaped by backslash again
  2. killall applet can cause troubles, because there may other applets running
  3. Save it as program

However it works well on 10.6.5

  • applet refers to?
    – Pacerier
    Dec 15, 2017 at 23:24

The following should let you specify command-line arguments for the .app itself:

Right click .app bundle, select "Show Package Contents", navigate to Info.plist, double click it, find Args key, edit.

I don't have an OS X machine handy right at the moment, so I can't check whether you could also do this to an alias (if you wanted to keep the original .app argument-free, et cetera).


Wrap your application inside an AppleScript launcher.

Here are the steps.

  1. Create an AppleScript with the following content, and save it as an application (in this example it is named "Firefox 3 launcher.app").

    set pathToApp to (POSIX path of (path to me)) & "Firefox 3.app"
    do shell script "open -a \"" & pathToApp & "\" --args -P default -no-remote"
  2. Got to that app in the Finder, right click it, show package contents.

  3. Put your application in the root of the package contents. (In this example it would be "Firefox 3.app")

    Result: /Applications/Firefox 3 launcher.app/Firefox 3.app

  4. You may now open your application launcher.


  • Automatic updates of the wrapped application should work in most cases.
  • It should be possible to make any drag and drop to the launcher automatically redirected to the wrapped application (with a bit more scripting).
  • The launcher automatically exits after the wrapped application is launched.
  • An advantage of this method is that there is few risks of opening the wrapped application directly.

Why don't you use:

open /Applications/Firefox.app

Simple but it works.

  • 2
    The terminal will open if you do that.
    – MJeffryes
    Aug 1, 2009 at 11:56

You must log in to answer this question.

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