Hive Hive
Sign in

Can support be added for /usr/bin/open -F which causes an app to open in a fresh state without restoring other windows?

GitHub issue · Open

Metadata
Source
tuist/tuist #6635
Updated
Jun 11, 2026
Domains
CLI
Details

What problem or need do you have?

This func spins up /usr/bin/open to open the project and I’m requesting that an option be made for allowing open’s -F flag so that when you open a project you can ensure others are closed.

This is particularly import in my org because we use tuist both for our main app as well as internal modules so if you have the app open and it depends on module A and then you generate module A you run into package resolution errors because the app depends on dependencies of module A.

Docs for -F flag:

-F Opens the application "fresh," that is, without restoring windows.
Saved persistent state is lost, except for Untitled documents.

Potential solution

In theory you could default to this being on but that might confuse or annoy people. I’m suggesting that we have something like --no-open to enabled this behavior.

macOS version

14.6

Tuist version

4.21.1

Xcode version

15.4

Comments
P
pepicrft Aug 12, 2024

@nickkaczmarek would you like to go ahead an open a PR?

D
dosubot[bot] Aug 13, 2025

Hi, @nickkaczmarek. I’m Dosu, and I’m helping the tuist team manage their backlog and am marking this issue as stale.

Issue Summary

  • You requested support for the /usr/bin/open command’s -F flag in Tuist to open apps in a fresh state.
  • This feature aims to help avoid package resolution errors when working with multiple projects.
  • You suggested an option like --no-open to enable this behavior without changing existing defaults.
  • A maintainer encouraged you to submit a pull request to implement this feature.
  • The issue remains unresolved with no further updates or contributions.

Next Steps

  • Please let me know if this feature is still relevant to the latest version of Tuist by commenting on this issue.
  • If I do not hear back within 7 days, I will automatically close this issue.

Thanks for your understanding and contribution!

N
nickkaczmarek Aug 13, 2025

Thanks @dosubot

I think this request still has value but I just haven’t had time to work on it.

D
dosubot[bot] Aug 13, 2025

@pepicrft Could you please assist @nickkaczmarek with this feature request for the /usr/bin/open -F flag support in Tuist? Thanks!

N
nickkaczmarek Aug 13, 2025

@pepicrft Could you please assist @nickkaczmarek with this feature request for the /usr/bin/open -F flag support in Tuist? Thanks!

I have that draft MR open. I just have to actually do the work. But like I said I still think this would be a good behavior to enable for users.

Don’t think I need much more assistance here in the issue. I just need time to do the work.

P
pepicrft Aug 14, 2025

@nickkaczmarek which API do you have in mind? Would the following make sense:

let tuist = Tuist(project: .tuist(generationOptions: .options(
openArguments: ["-F"]
)))
N
nickkaczmarek Aug 14, 2025

@nickkaczmarek which API do you have in mind? Would the following make sense:

let tuist = Tuist(project: .tuist(generationOptions: .options(
openArguments: ["-F"]
)))

I was thinking this would be something we’d pass as part of a generation command via the cli. Essentially what I’m going for is I have many Xcode things open, I’ve quit Xcode, and now I’d like to generate but have only the thing I’m generating open.

My particular use case is at work I often have many instances of Xcode open and sometimes I’d like a clean slate when opening our monorepo. So what I do today is quit Xcode then run open -F to get a clean Xcode and then generate.

Importantly though I see this as an option and not a default. I don’t want to always clean open but I’d like the option to without having to know how open works.

N
nickkaczmarek Aug 14, 2025

I guess this might also be useful for things like edit and other commands I’m less familiar with. The issue that led me to the behavior is that every instance of Xcode freezes if even one of them does and to mitigate that I just close them all unceremoniously.

P
pepicrft Aug 14, 2025

In that case, what about:

tuist generate --open-args "-F"

That way the caller has full flexibility to decide which arguments they’d like to pass to the underlying open process.

N
nickkaczmarek Aug 14, 2025

In that case, what about:

tuist generate --open-args "-F"

That way the caller has full flexibility to decide which arguments they’d like to pass to the underlying open process.

Yeah that seems like it would work. Though I wonder if that implies other open options are available.